PHP error when trying to disable jetpack modules

  • Resolved webwitnl

    (@webwitnl)


    3 years, 6 months ago

    Hi, I run the latest of WordPress and Woocommerce. When I go to the Jetpack dashboard, scroll to the bottom and click Modules, I can activate or deactivate modules.

    Whatever module I try to deactivate, I get a critical error.

    Looking at the php error log, I see the stack trace below. It is the log() function which tries to do “$log = array_slice( Jetpack_Options::get_option( ‘log’, array() ), -199, 199 );” but get_option(‘log’) apparently gives boolean false.

    PHP Fatal error: Uncaught TypeError: array_slice(): Argument #1 ($array) must be of type array, bool given in /home/xxx/public_html/wp-content/plugins/jetpack/class.jetpack.php:3086

    Stack trace:

    #0 /home/xxx/public_html/wp-content/plugins/jetpack/class.jetpack.php(3086): array_slice(false, -199, 199)

    #1 /home/xxx/public_html/wp-content/plugins/jetpack/class.jetpack.php(4014): Jetpack::log(‘deactivate’, ‘stats’)

    #2 /home/xxx/public_html/wp-content/plugins/jetpack/_inc/lib/admin-pages/class.jetpack-admin-page.php(171): Jetpack->admin_page_load()

    #3 /home/xxx/public_html/wp-includes/class-wp-hook.php(307): Jetpack_Admin_Page->admin_page_load(”)

    #4 /home/xxx/public_html/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters(NULL, Array)

    #5 /home/xxx/public_html/wp-includes/plugin.php(476): WP_Hook->do_action(Array)

    #6 /home/xxx/public_html/wp-admin/admin.php(237): do_action(‘load-toplevel_p…’)

    #7 {main}
    thrown in /home/xxx/public_html/wp-content/plugins/jetpack/class.jetpack.php on line 3086

Viewing 8 replies - 1 through 8 (of 8 total)
  • Bruce (a11n)

    (@bruceallen)

    Happiness Engineer

    3 years, 6 months ago

    Hi @webwitnl

    Could you please post your site URL here so that we can have a look?

    If you want it to remain private, you can also contact us via this contact form. If you choose to reach out directly, please include a link to this thread.

    Thanks!

    Thread Starter webwitnl

    (@webwitnl)

    3 years, 6 months ago

    Hi Bruce, it’s https://www.wildewolf.nl/
    Thanks!

    Plugin Contributor Dan (a11n)

    (@drawmyface)

    3 years, 6 months ago

    Hi there

    Thanks for sending the stack trace, that’s a big help.

    It seems like something has hooked “jetpack_options” and is returning false. Or else something earlier in the request is consistently setting false for the relevant option. The fact that it’s getting false indicates it’s not something stored in the database, as trying to store false here would come back as the empty string instead.

    I think we need to rule out a conflict with another plugin/theme at this point. Would you be able to deactivate all other plugins and switch to a default theme (you could use a staging site, or try the troubleshooting mode of the Health Check plugin if you don’t want to do it on your live site).

    You could also try searching the source code of any active plugins for references to strings jetpack_options, jetpack_log, or a string log being passed to methods on class Jetpack_Options as a starting point.

    Please let us know what you find.

    Thread Starter webwitnl

    (@webwitnl)

    3 years, 6 months ago

    I did a bit of digging and traced the flow of code.

    The problem is the code calls a function maybe_unserialize() in wp-includes/functions.php, which calls php’s unserialize() with the value of jetpack_log in database table wp_options.

    There’s a serialized string in that database field, but unserialize gives an error and returns bool false.

    PHP throws this notice:
    Notice – unserialize(): Error at offset 2045 of 36021 bytes

    Looking at the string at offset 2045, I see nothing special. The field is a proper longtext in utf8mb4_unicode_ci and isn’t cut off. I also tested the string somewhere else at http://php.fnlist.com/php/unserialize where it gives the same error at offset 2045.

    If you want I can privately share the string with you.

    • This reply was modified 3 years, 6 months ago by webwitnl.
    Thread Starter webwitnl

    (@webwitnl)

    3 years, 6 months ago

    Found it. Before offset 2045 the serialized string does something like this:

    s:71:”/home/xxxxxxxxx/public_html/wp-content/upgrade/wordpress-5.9-nl_nl/”

    That string is not 71 characters long but 67.

    I fixed it in the database, but then it failed on a next path with also a length 4 characters too long:

    s:52:”/home/xxxxxxxxx/public_html/wp-content/languages”

    It’s 48 characters.

    I never changed paths nor the xxxxxxxxx part.

    Hmmm….

    Plugin Support lastsplash (a11n)

    (@lastsplash)

    3 years, 6 months ago

    Hi @webwitnl –

    Thanks for the additional information.

    Our development team believes the values in your database are subtly corrupted and that is what is causing the issue. The maybe_unserialize() identified (presumably the one here) is already inside WordPress core, not in Jetpack. It seems unlikely to have been Jetpack doing it as all accesses in Jetpack code for this option will go through the WordPress core functions.

    It should be ok for you to just delete the row from the database, it’ll just lose some logging information. That said, it is always a good idea to back up your site before modifying the database so that you can restore your site if something goes awry.

    After that, if can reproduce the problem again reliably, you might check whether what is going into the database (here or here) matches what is coming out.

    Thread Starter webwitnl

    (@webwitnl)

    3 years, 6 months ago

    Yeah it’s a weird one. I can think of two possibilities, one is serialize() used to be famously bugged especially with nested arrays, but that was years ago and surely fixed with PHP8 we’re running. And two, maybe it was manually edited at the beginning by someone when we set up the site on dev and moved to prod, but the filepaths on dev are much longer and doesn’t explain 4 characters.

    Anyway, I fixed the lengths of the paths manually, and it works now. Thanks for your time and help!

    • This reply was modified 3 years, 6 months ago by webwitnl.
    Plugin Support lastsplash (a11n)

    (@lastsplash)

    3 years, 6 months ago

    You are welcome!

    I’m going to mark this thread as resolved. If you need assistance with Jetpack in the future, feel free to open a new thread.

Viewing 8 replies - 1 through 8 (of 8 total)

The topic ‘PHP error when trying to disable jetpack modules’ is closed to new replies.