Site times out from transient_keys and cache_keys

Thank you @cliffseal, I have commented out the lines and removed the two fields.

Implemented this solution and the issue still remains.

    static function call_api( $key, $args ) {
		//$value = self::get_cache( $key );
		//if ( ! $value ) {
			$auth = Pardot_Settings::extract_auth_args( $args );
			$args['new_api_key'] = array( __CLASS__, '_new_api_key' );
			$value = self::get_api( $auth )->{"get_{$key}"}( $args );
			//self::set_cache( $key, $value );
		//}
		return $value;
	}

After doing the above we’ve deleted the two mentioned rows from the wp_options table as suggested and flushed our caches (unsure if this helps but made sure it was done anyway).

Nothing loads on the plugin page, widgets, or customizer.

For the above code if we comment out the entire call_api section, the plugin settings screen then displays. In this situation through we cannot access the widget area or the customizer due to a PHP missing call_api function so it’s not too much help.

You mentioned above a planned release for an update / fix, may I ask when this is scheduled?

Thanks in advance for your time and support,
Alex

• This reply was modified 5 years, 10 months ago by alexhighhigh.

@alexhighhigh Hmm, I think something else may be going wrong. You’re the first person to report those sorts of issues after implementing this change.

Can you look for any errors that might point you towards a missing semicolon or bracket, or just double-check to ensure there weren’t any changes beyond commenting those four lines out?

Thanks @cliffseal!

We have deleted and re-added the plugin. After adding again I edited the PHP file and commented out those four lines (on a fresh install of Pardot from the WordPress directory).
A short while after the new install our client logged in and authenticated the Pardot plugin with their login and API. I have just logged in to check and now cannot load the Pardot settings page: /wp-admin/options-general.php?page=pardot

This results in a 404, which is probably the security plugin denying any script from running for longer than 30 seconds. Is this long delay normal/expected behaviour?

Hey @alexhighhigh,

You seem to be describing a 500-type error—if that’s the case, can you ensure your client has IP Security set up correctly? For the plugin to work, it either needs to have the server IP address(es) whitelisted or be disabled entirely.

This worked great for us @cliffseal . No more giant wpdberror string embedded in the html with lots of \" etc! Thanks for the hotfix! When this is fixed iin the plugin, please add it to the plugin’s changelog, so we don’t have to implement the hotfix on each version upgrade. Thanks again!

@yuviliom This will definitely be in the upcoming release. Thanks for your patience.