cc_sam

(Edit: We’re still on the latest WP repo version)

I would assume it depends on website traffic, for us we last wiped the data in December when we found the array was at ~110,000. We also turned off the autoload option at that time. Yesterday we saw the _pardot_cache_keys array was at ~700,000 and causing downtime so we wiped it again. Right now (24 hours later) it’s at 53864.

This error was being triggered 1-2 times per second:
WordPress database error Got a packet bigger than ‘max_allowed_packet’ bytes for query UPDATE wp_options SET option_value = ‘a:674976:{i:0;s:7:\\”account\\”;i:1;s…….

Looking forward to seeing an updated version
Thanks for your efforts!

• This reply was modified 6 years, 1 month ago by cc_sam. Reason: added clarification

I found the same problem today. Our site was giving 504 errors and after a few hours of troubleshooting we found it was due to this data. The combination of _pardot_transient_keys and _pardot_cache_keys resulted in ~5MB of data in the DB. Since autoload is set it “yes” it was causing 504 errors.

See data: https://imgur.com/a/sTDzTGB
Platform: WP Engine
PHP: 5.6
WordPress: 4.9.8

The solution for us was setting autoload to “no” for these two rows, however the bigger question is why this data exists in the first place. For us it’s a serialized array of 110,000 items all with the same string data “pardot_account”.

Thanks
-Sam

As of this morning I no longer see the issue.

The banner and message to active is gone: https://i.imgur.com/7yMZe8M.png
The setting for JSON API is now checked as I would expect: https://i.imgur.com/v5SfVuP.png

I’ll be installing Jetpack on more sites today. I’ll report back if I notice the issue again.

-Sam

Looks like it may just be a bug. I’ve had the same issue on 1 of the 10 sites I’ve enabled Jetpack on.

Edit (additional details about the 1 site with the issue):

When clicking activate the setting appears to be changed in the DB:
https://i.imgur.com/9uy8mHu.png

However the admin interface and green banner are not seeing it’s already active:
https://i.imgur.com/rAXrehL.png

View post on imgur.com

Perfect, thanks Tara.

Thanks for the update Frankie, looking forward to being able to add new sites again.

Same issue for us again. It worked for a little while a few days ago, but now it’s back to being broken.

I’ve had a chance to try installing Stream on a few other WP installs and web hosts. All installs provide the same Error 104, so I’m assuming it may be an issue on Stream’s end.

I just got the error as well (9:15am PT)

“Stream API Error. Operation timed out after 10000 milliseconds with 0 bytes received.”

Same thing here, I first noticed the issue around 24 hours ago

Hi Frankie,

With version 2.0.1 of Stream the issue no longer occurs. I’m able to create new posts with ACFs, or save existing ACF data without the fields being wiped.

Thanks for fixing this
-Sam

Hi Frankie,

I’ve had a chance to test more thoroughly and have tried ACF with Stream 2.0 on a fresh WP install with the same issue. When publishing a new post none of the ACF data is saved. When saving an existing post with ACF data it gets wiped out.

Hi Frankie,
Thanks for the reply

I downloaded that zip and uploaded it replacing the existing stream folder. I’m experiencing the same issue. When I attempt to use a page with ACFs the data is wiped.

It’s worth mentioned when I compare the folder of Stream files from earlier this morning with the freshly downloaded URL you provided the files contained within are identical according to WinMerge.

Is there another source of 2.0 you can provide me with? (dropbox, git, etc)

I’ll take a more thorough look tomorrow morning.
Thanks