After updating to Beaver Builder Pro Version 2.9.0.4, we encountered the following fatal error:
PHP Fatal error: Uncaught TypeError: key(): Argument #1 ($array) must be of type array, string given in /wp-content/plugins/bb-plugin-pro/classes/class-fl-builder-fonts.php on line 767.
It seems the variable passed to key() is a string instead of an array, likely causing a type mismatch under PHP 8.x.
Environment:
WordPress version: 6.8.2
PHP version: php8.4
Theme: Custom Theme
Other active plugins: [Advanced Custom Fields, Classic Editor, Members, Multiple Post Thumbnails, Yoast SEO]
Please let us know if this issue has been patched in a newer release or if there’s a recommended workaround.
Its going to be hard to debug this sort of issue, you will need to open a ticket so we can have a closer look. Have you tried a more recent version from your account?
I needed to create a safeguard to catch the error, as it currently breaks the site when using the Beaver plugin. The admin access is disabled for the public site. For safety, all our admin functions are only accessible internally.
ok well in that case you will have to do the debugging for us, as we have no access to your site.
You will need to edit that file and add some debugging, like use var_dump to see what the variable actually is, it should be an array but its a string, so what is the value of $json immediatly before the fatal error?
Please on you update put the safety validation so that when that file data format changes its does not fail to fatal error like it have done. make you code safety for any impossible solution so that it resolve with out breaking e.g $json = self::_get_json();
foreach ( $json as $k => $font ) {
try {
if(is_array( $font ) && !empty( $font )){
$name = key( $font );
foreach ( $font\[ $name \]\['variants'\] as $key => $variant ) {
if ( 'italic' !== $variant ) {
if ( stristr( $variant, 'italic' ) ) {
$font\[ $name \]\['variants'\]\[ $key \] = str_replace( 'talic', '', $variant );
}
}
if ( 'regular' == $variant ) {
$font\[ $name \]\['variants'\]\[ $key \] = '400';
}
}
$fonts\[ $name \] = $font\[ $name \]\['variants'\];
}
} catch (Throwable $e) {
}
} this was the fix I have to put in place why your file was broken to bring the site up. i will suggest that for all you dynamic file you try safety code to make sure your code do not affect us at all please. let me know if those update are done and they will not affect us on the fucture.
Have you tried using the latest version? I have tried to replicate an issue and I am not seeing it. Even if I physically delete the json file, block internet and delete the transient I do not see the fatal error.
Please update to the latest version, we cant support debugging old versions.
Please note that the error was not caused by a missing file. Based on the error message, it appears that during the file update, a key-value pair was generated as strings instead of the expected array, which caused the key() function to fail and trigger a fatal PHP error.
I should mention that I can no longer reproduce the issue — it only persisted for about an hour before disappearing. Whatever you did during that one-hour window seems to have fixed the file, but it does not address the root cause or safeguard against the same issue happening again during future edits or updates.
Simply upgrading will not prevent this type of issue from recurring, as the code currently lacks proper validation on the affected line. To ensure stability, you should add checks when looping through the fonts.json array. This will prevent the function from throwing a fatal PHP error if the array structure breaks, especially since the function is hooked to the site header.
Also, this issue involved version 10.2. At the time the error occurred, I did upgrade to that version(10.2), but the problem still appeared within that same one-hour window. After reviewing the code in both versions, I confirmed that there were no changes implemented to validate or safeguard against the root cause.
This means that for us to continue using the plugin safely, we would have to keep manually editing it and add safe validation to prevent the error from possible happen in future and the error scaling into PHP fatal error — which is not an ideal or sustainable solution. We are also contributing under the license, so please take this matter seriously, as it may affect other clients using the same plugin. when you do your changes as you mention you make changes daily on that file.
Im guessing this is lost in translation with whatever you are using.
In latest versions the font json is loaded periodically and saved in the database as a transient. I have tested with and without that url working, I have deleted the transient, I have tried everything to make that data broken somehow using the latest release version but I cannot replicate it. The issue might be as I have already mentioned is that you are using a really old version of the plugin, we test issues using the latest versions, have you tried updating to the latest version?
I’ve already explained that the issue no longer occurs, and it’s unclear what exactly changed in your file during the time. However, my main concern is with how your system reads and formats the file. Whether or not the data is saved correctly to the database is not the issue at this point. My concern is that your code lacks proper validation, which is why the broken file caused our site to go down.
After reviewing the code in your latest plugin version, which I’m currently testing, it still does not include proper data validation before calling the key() function. This means the same issue could happen again if similar changes occur that break the file, which at this point I can tell you as you can not also tel me. Like I said for low traffic site that issue will be not easy to pick it up as its also happen on one site and not all site in our side which update you did that date was the course as after one hour all that disappeared. Can you make sure you do proper data validation and mitigate the fatal errors to never happen?
Yea, the JSON if downloaded and proper JSON will not have a fatal with the key function because the key will always exist, if the file is not JSON the file is not used and ignored and no fonts are added, thats how it is in the latest version, but like I said you are using a very old version.
