Uncaught TypeError after update to 1.5.2

Update: issue is carried over following the 1.60 update (error line has moved).

Uncaught TypeError: Unsupported operand types: float / string in /home/xxxxxxx/public_html/wp-content/plugins/system-dashboard/admin/class-system-dashboard-admin.php:6464

@ivanarnaudov just saw this. Can you test again with 1.9.0?… 2.0.0 is just around the corner, feel free to wait for that too. Thanks!

@ivanarnaudov also, can you let me know your server/hosting setup? The error has to do with Disk Usage monitoring.

Hi @qriouslad, thanks for responding. I am using shared hosting (Litespeed) and can reproduce the issue under PHP 8.0/8.1. The code executes under PHP 7.4 and earlier versions with some non-breaking issues.

I believe the root cause for the problem is a combination of a configuration limitation of my host under PHP 8.x and a mishandling of the ‘Disk Usage’ string on your end.

1. The configuration limitation is that my host allows exec() but does not have a setting to allow shell_exec() and it makes it impossible to extract the needed values to work with on your end. In both PHP 7.4 and PHP 8.0, your module reports CPU uptime, Load Average, RAM usage and the output of sd_total_disk_space() as ‘undetectable’.

(I tested that last one by replacing the whole line that populates the ‘Disk Usage’ content with 'content' => $this->sd_total_disk_space() to see what happens.)

Maybe consider using exec() instead of shell_exec()? I don’t have a lot of experience with PHP but the way I see it, exec() can be made to return the full output of a command as an array, and will even return a stat code for successful operation completion?

2. The problem with your code is that it will use the output of sd_total_disk_space twice on that line regardless of whether it returns a numeric value or ‘undetectable’. PHP 7.4 lets this slide by throwing a series of warnings (non-numeric value detected, division by zero) but PHP 8.x is more strict about casting strings as ints and floats, and will have none of it. That is why under PHP 7.4 I get a <strong>Disk Usage</strong> 1 TB free (INF%) of bytes total message but under PHP 8.x WordPress breaks completely.

While there is obviously nothing you can do about my host configuration, I believe with this information you will be able to improve the process of reporting disk storage to allow for ‘undetectable’ total disk space.

A separate issue: You have a typo within sd_site_health() on line 366 in the same file (misspelled $output as $ouput in the $issues_total count check). In case your line numbering has changed, this screenshot refers: https://i.imgur.com/naKHCSZ.jpg

• This reply was modified 2 years, 8 months ago by Ivan Arnaudov.
• This reply was modified 2 years, 8 months ago by Ivan Arnaudov. Reason: Improved suggestion

@ivanarnaudov thank you for investigating this in great details!

I’ve revisited the code around disk usage and made some changes that should fix the TypeError issue and make the message displayed more uniform when shell_exec is not enabled. I will keep in mind about the possibility of using exec instead of shell_exec.

I’ve also fixed the typo in sd_site_health(). Thanks!

Please update to v2.0.2 which I’ve just released and let me know if that works better for you.

I rarely use Litespeed-powered server/hosting, and will spend some time playing around with it for a future release. Currently only doing tests with NGINX and Apache servers.

Please update to v2.0.2 which I’ve just released and let me know if that works better for you.

Yes, it works now without issues. Tested up to PHP 8.1

I rarely use Litespeed-powered server/hosting, and will spend some time playing around with it for a future release.

No need for specific testing as far as my experience shows. Litespeed is designed to be drop-in compatible with Apache, and the only significant difference is that their team compiles and packages PHP themselves, which means sometimes they might be a minor version behind the most current version for a given PHP branch.

Anyway I will be putting your plugin onto several websites under different Litespeed servers and will hopefully be able to catch and report other issues, if any.

Thanks for taking care of this! Marking this thread as resolved.

@ivanarnaudov awesome! Thanks for the explanation about Litespeed being drop-in replacement for Apache. Good to know. I do have a site on Litespeed I can test on, just for the sake of completeness.

Let me know the results of your further tests and if you have specific feedback on how this could be more useful for your work. Would also love to hear how what exists now is already useful under which scenario(s). Thanks!