xzistance3

I found this thread tonight and am wondering if something larger is going on with the Smush plugin.

A site that I develop on has started having slow load times — meaning, server response time is slow during the back-end processing with PHP and MySQL as it generates the HTML output.

I’ve tested this in multiple environments (staging and prod) and when I disable Smush, the load times get almost cut in half.

Some example load times of the same homepage with Smush activated:
25.89s
22.27s
23.86s

Example load times after deactivating Smush:
6.29s
7.57s
6.37s

These load times are with page caching disabled.

I feel something is going on during load-up with Smush. Almost seems like it’s trying to connect to something off-site (API, perhaps?) and is chugging and waiting for a response and maybe it times out or it eventually connects and does whatever it has to do and then continues on. I’ve had to deactivate the plugin for now.

• This reply was modified 2 years, 3 months ago by xzistance3.

FYI, I submitted a help ticket on support.auth0.com — If you’re able to utilize that system, we can exchange more detailed info. Request # is 36989

I double checked the 2 Client Grant errors and the Client should have those grants enabled.

Thanks Josh.

Here are some of the errors I’m getting in the log:

03/08/2018 19:44:38	WP_Auth0_Api_Client::get_client_token	N/A	{"error":"access_denied","error_description":"Client is not authorized to access \"https://[TENANTID].auth0.com/api/v2/\". You might probably want to create a \"client-grant\" associated to this API. See: https://auth0.com/docs/api/v2#!/Client_Grants/post_client_grants"}

03/08/2018 19:44:33	WP_Auth0_Api_Client::get_client_token	N/A	{"error":"access_denied","error_description":"Client is not authorized to access \"https://[TENANTID].auth0.com/api/v2/\". You might probably want to create a \"client-grant\" associated to this API. See: https://auth0.com/docs/api/v2#!/Client_Grants/post_client_grants"}

03/08/2018 19:44:31	WP_Auth0_DBManager::install_db	N/A	Unable to automatically update Client Grant Type. Please go to your Auth0 Dashboard and add Client Credentials to your Client settings > Advanced > Grant Types for ID [CLIENTID]

03/08/2018 19:44:31	WP_Auth0_Api_Client::get_client	N/A	{"statusCode":401,"error":"Unauthorized","message":"Bad audience: [SITEURL]"}

03/08/2018 19:44:31	WP_Auth0_DBManager::install_db	N/A	Unable to automatically update Client Grant Type. Please go to your Auth0 Dashboard and add Client Credentials to your Client settings > Advanced > Grant Types for ID [CLIENTID]

03/08/2018 19:44:31	WP_Auth0_Api_Client::get_client	N/A	{"statusCode":401,"error":"Unauthorized","message":"Bad audience: [SITEURL]"}

03/08/2018 19:44:30	WP_Auth0_DBManager::install_db	N/A	Unable to automatically create Client Grant. Please go to your Auth0 Dashboard and authorize your Client [CLIENTID] for management API scopes update:clients, update:connections, create:connections, read:connections, create:rules, delete:rules, read:users, update:users, update:guardian_factors.

03/08/2018 19:44:30	WP_Auth0_Api_Client::update_client	N/A	{"statusCode":401,"error":"Unauthorized","message":"Bad audience: [SITEURL]"}

03/08/2018 19:44:30	WP_Auth0_Api_Client::update_client	N/A	{"statusCode":401,"error":"Unauthorized","message":"Bad audience: [SITEURL]"}

• This reply was modified 6 years, 8 months ago by xzistance3.

I’m having issues with this as well. I tried both of the options available, but I can’t get it to go away and work.

IMPORTANT!

WP-Auth0 has upgraded to 3.5.2 but could not complete the upgrade in your Auth0 dashboard.	This can be fixed one of 2 ways:

1. Create a new Management API token and save it in the Auth0 > Settings > Basic tab > API Token field.	This will run the update process again.

2. Review your Client advanced settings, specifically the Grant Types, and authorize your client for the Management API to manually complete the setup.

This banner will disappear once the process is complete.

I added all of the GRANTS to my Client from the new API that I created — they match what’s shown here: https://auth0.com/docs/cms/wordpress/configuration#authorize-the-client-for-the-management-api

What am I missing?

Thanks for the help. I was running into issues b/c I think the plugin detected that it had already optimized the images in the folders, so I ended up creating a custom script that checked all jpgs, jpegs, and pngs, and if there wasn’t a corresponding .webp image, it tried generating one.

This worked pretty well!

Thanks for the quick response. In a testing environment I’m trying this. Is there anyway to exclude our theme’s directory from being automatically scanned?

This is the fix from what I can tell.

Change that line to this:

if( $now + ($days*3600*24) > $level->enddate )

This checks to see if the membership expiration date is within the membership length. ie. If the expiration date is within 1 year, it’ll return true and show the ‘Renew’ option.

I hacked the plugin until a fix is released b/c my site is live and needs it too.

I’m still trying to debug this, but I think the issue may be on line 225 of /paid-memberships-pro/includes/functions.php:

if( $now + ($days*3600*24) < strtotime( $level->enddate, $now ) )

This method returns false:

strtotime( $level->enddate, $now )

From what I can tell, $level->enddate is already a unix timestamp, and perhaps why the function is returning false for an error.

I’m having the same issue. I swear the ‘renewal’ button use to be there, but now I can’t find it anywhere.

I am testing with non-recurring memberships who are logged in and should be seeing ‘Renew’ as a button on the membership levels page. Instead, I just see a ‘Your Level’ button grayed out or ‘Select’ next to other alternative levels.

Did the latest update nuke the Renew button by accident? Please help!

I’ve been having the same errors happen on a client’s server to the point where Media Temple thinks it could be significantly affecting the site performance. So, I’ve had to investigate further.

All the research I’ve done seems to point to plugins not properly calling the wp_cache functions. But, all of these errors seem to be happening on line 93, which is attempting to get a cache object. Here is the current 3.2 code for that function:

function wp_cache_get($id, $flag = '') {
	global $wp_object_cache;
	return $wp_object_cache->get($id, $flag);
}

My question is.. why doesn’t this function check to see if the $wp_object_cache has been set and/or the get() function exists? This seems to be a common error happening among lots of wordpress sites.. couldn’t we just update this function to look something like this?

function wp_cache_get($id, $flag = '') {
	global $wp_object_cache;
	if (isset($wp_object_cache)) {
		return $wp_object_cache->get($id, $flag);
	}
}

I figured this out.

For whatever reason, the network update wasn’t working, but if I went to my secondary blog’s wp-admin/upgrade.php file, it allowed me to update it:

https://mysite.com/secondaryblog/wp-admin/upgrade.php

I ran the upgrade from this URL and now the backend admin works fast! w00t!

Is there any way to run a script specifically on each blog in the MU without having it to connect to that Network Update thing?

I feel like there should be a way to run a file locally and manually or something..

@ipstenu: I understand what you’re saying, but I know the two servers are talking back and forth very fast. Nothing has changed on that end. We have a few other sites that are hosted on the same platform and they are working just fine. Like I said, it’s ONLY when trying to use the admin of the other microsite. The front-end of that blog works fine and fast, as does everything else.

These two servers have been working together seamlessly for over 2 years, so it’s not that. It’s something in the code or something that changed or didn’t change in the database. Nothing else makes sense. Everything was working perfectly fine until I upgraded to 3.1

I have one additional blog other than the main one on my MU install. So, 2 total blogs. And the DB is on a separate server dedicated for just the DB. I don’t know exactly how much there is, but there’s plenty, promise.

I have tried disabling the admin bar; both through the plugin and adding a line to my functions file. And there’s at least 512 MB of php memory. Might even be 1024