Fatal Error: PHP 7.2 Syntax Error (breaking whole site)

I found my site (which happens to be on PHP 7.2.x still for other reasons) was giving me a fatal error of:

Parse error:
syntax error, unexpected ')'
in /wp-content/plugins/user-activity-tracking-and-log/class-moove-activity-options.php
on line 107

This plugin currently doesn’t have its PHP version requirement listed in the plugin details so my site was just freely able to update automatically where it then had code that didn’t work well with particular PHP versions (subsequently bringing the entire site down in the process.)

Thankfully, this is a quick & straightforward fix (with 1 code change to fix the issue & 1 other thing to help prevent this in the future.)

The cause of the error for the PHP version is:

add_submenu_page(
        'moove-activity-log',
        $plugin_tab['title'],
        '<span class="uat-menu-item uat-menu-item-' . $plugin_tab['category'] . ' ' . ( $curren$                                $permission,
        $plugin_link . '&tab=' . $plugin_tab['slug'] . '&sm=' . $plugin_tab['category'],
);

in /wp-content/plugins/user-activity-tracking-and-log/class-moove-activity-options.php around line 107.

You can see how there’s a trailing comma at the end of the function parameters. It’s totally unnecessary & isn’t doing anything other than adding a comma that doesn’t need to be there while it then causes server errors for certain PHP versions (they’re okay with a comma at the end of something like an array [while still a bit unnecessary… it doesn’t break anything], but doing the same with function attributes was made to throw an error for some PHP versions.)

Simply deleting that one comma at the end of the function parameters to make that code become:

add_submenu_page(
        'moove-activity-log',
        $plugin_tab['title'],
        '<span class="uat-menu-item uat-menu-item-' . $plugin_tab['category'] . ' ' . ( $curren$                                $permission,
        $plugin_link . '&tab=' . $plugin_tab['slug'] . '&sm=' . $plugin_tab['category']
);

fixes the issue (at least the site-wide error) where it, thankfully, doesn’t appear to be present in other files.

As such, I’d recommend patching this sooner than later since the fix is super straightforward (remove a comma that isn’t doing anything other than breaking some sites) which hopefully is patched before others with a similar setup find that updating this plugin to this current version causes a site-wide error then requiring them to delete the plugin files or patching their code manually to bring it back.

Also, it’s probably worth adding the PHP version requirement in the plugin’s info (which was added as something plugins could/should do years ago per https://make.www.ads-software.com/plugins/2017/08/29/minimum-php-version-requirement/.) That way, one can work on & maintain the plugin while expecting something like PHP 7.4+ while sites on older PHP simply keep the last version of the plugin that was confirmed as working for that PHP version while they can resume future plugin updates after they’ve updated their PHP which should be done at some point anyway (reducing the need to test against a ton of PHP versions that really should be phased out at a certain point during plugin development/updates & also helps make sure users of the plugin don’t find their site breaking due to a plugin update that doesn’t play nice with their PHP version.)

I might suggest doing a hotfix where the current version 4.0.0 of this plugin is silently updated to mention the PHP 7.3+ (or whatever) PHP version requirement so sites on older PHP will never update to this version that had code with this requirement. Meanwhile, 4.0.1 can then be rolled out that doesn’t have the problematic comma being used while still then having the PHP version requirement (possibly PHP 7.2+, or even lower, at that point since the compatibility issue has been resolved) while it then sets the PHP version requirement convention to then be changed to a newer version if/when needed in future releases. Though it might be fine with just the 4.0.1 fix where it’s fixed & has the PHP version requirement convention set and everyone just moves on from 4.0.0 (as long as the PHP version requirement isn’t higher than 7.2 since having this release require a higher version of PHP leaves people with that version having their site still wanting 4.0.0 where the issue was & then being unable to get the patched 4.0.1 plugin update [effectively making it so they’d be stuck with this plugin ending on a broken version for them.])