MadeByCaliper

@goran87 I’ve spent about a week trying to debug this and was so confused bc I was also testing in Postman, which works with the Bearer {{token}} and stuff. Rollback to JWT v1.2.4 for now.

@jbaylo There are a couple things wrong in your code:

1. The docs show an example that uses time(), not the argument passed through the action (the var you’re calling $issuedAt. Change your code to return time() + (DAY_IN_SECONDS * 90);

2. You’re also using add_filter() where you should be using add_action(). Change the code to add_action('jwt_auth_expire', 'test_jwt_auth_expire');

Did some more digging and found that it seems to do with the decompress arugment defaulting to true for the WP_Http class. If you change the SendGrid class-sendgrid-tools.php to include a 'decompress' => false argument it seems to remove the error and still function correctly. Don’t know if this is proper, but it seems like a fix:

L80 :

$args = array(
      'headers' => array(
        'Authorization' => 'Bearer ' . $apikey ),
      'decompress' => false
    );

I pulled it from this SO thread:
WordPress gzinflate() error

Also getting this error with WP 4.5.3 with PHP 5.4.42. Query monitor output:

gzinflate()
 wp-includes/class-wp-http-encoding.php:58
WP_Http_Encoding::decompress()
 wp-includes/class-wp-http-curl.php:293
WP_Http_Curl->request()
 wp-includes/class-http.php:433
WP_Http->_dispatch_request()
 wp-includes/class-http.php:342
WP_Http->request()
 wp-includes/class-http.php:496
WP_Http->get()
 wp-includes/http.php:170
wp_remote_get()
 wp-content/plugins/sendgrid-email-delivery-simplified/lib/class-sendgrid-tools.php:85
Sendgrid_Tools::check_api_key_scopes()
 wp-content/plugins/sendgrid-email-delivery-simplified/lib/class-sendgrid-tools.php:135
Sendgrid_Tools::check_api_key()
 wp-content/plugins/sendgrid-email-delivery-simplified/lib/class-sendgrid-statistics.php:69
Sendgrid_Statistics::add_statistics_menu()
 Unknown location
do_action('admin_menu')
 wp-admin/includes/menu.php:149

Just checked out that Github issue and it definitely sounds like it’s related. Unfortunately I don’t know enough about OOP to chime in very constructively…

I did a little testing and it seems like the difference of the WP-CLI activate and “manual” activation is the db.php file being symlinked. John, does this help identify where the init sequence is stalling? (Also updated the Github ticket)

Thanks John. Sorry I didn’t take the time to respond to your initial response. I have a little more time to help you investigate or give feedback if you need it, so please let me know.

No problem yall. Happy to contribute.

Greg I couldn’t find any background videos on any of the sliders. Is that what the JSON output suggests?

So I pulled down the 1.4 update and deleted then recreated the Slider widget that was working with 1.3.1 and compared the JSON outputs from the different versions. After some trial and error I found that the when the url property has something in it, it breaks my layout. Changing everything else didn’t seem to cause any problems, even passing the frames property as an object vs. array in 1.4. Below is the JSON with the url property that’s breaking stuff.

Hope this helps you isolate the issue!

...
      "frames": [
        {
          "background_image": "813",
          "background_image_type": "cover",
          "foreground_image": "0",
          "url": "https://test.net",
          "new_window": "on"
        },
        {
          "background_image": "806",
          "background_image_type": "cover",
          "foreground_image": "0",
          "url": "https://test.net",
          "new_window": "on"
        },
        {
          "background_image": "805",
          "background_image_type": "cover",
          "foreground_image": "0",
          "url": "https://test.net",
          "new_window": "on"
        }
      ],
...

Yea Greg I am using Page Builder. Sorry I didn’t mention that in the comment. And thanks for getting back so gosh dang quick!

So do I use the WP export tool or should I grab it from the DB or something? Let me know and I’ll do it for you.

Thanks for responding so quickly!

Yea I guess a filter would be a fine solution, sure. However, I think that would limit the flexibilty of the plugin. Consider the use-case of someone who doesn’t want/know how to modify the code of a theme, but could upload some images to a folder via FTP really easily…they’d probably be comfortable using your existing “custom icons” feature, but if they wanted to port the theme to a different server they’d have to change the icon location based on the host config. My suggestion sovles the problem without requiring the user to touch the code, whereas using a filter would require knowledge of WP, which I have, but others may not.

Either way, having some sort of option to implement this would be awesome. And then when my client updates your plugin they won’t lose the functionality I built in ??

Thanks again

I just got the same error and modified the code to pass a non-anonymous function. Now it works. Replace the add_action() code with the following and it should fix the error:

function add_snitch() {
	if (current_user_can('manage_options'))
	{
		new AcfFieldSnitch();
	}
}

add_action('init', 'add_snitch');

Looks like it’s working consistently now, thanks! I guess I’ll just update when you release a stable build of 2.2.0?

Thanks again for your work on this.