metricmedia

I see the reference in your docs page linked above, but it doesn’t specify what the rules are WP Engine should add.

My support tech dug a bit and found them:

if ( $http_accept ~ "image/webp" ) {
set $webp '.webp' ;
set $type 'image/webp';
}
location ~* .(png|jpe?g|gif)$ {
add_header Vary Accept;
add_header X-Type "static/known";
add_header Cache-Control "public, max-age=2592000";
add_header Vary "Accept-Encoding";
add_header Access-Control-Allow-Origin *;
add_header content-type $type;
default_type '$type';
try_files $uri$webp $uri =404;
}

Does this look current & correct to you?

One question: what happens if there is no webp image for a given image? Does this load the original jpeg/png? Or do we get a missing image?

I see this happening on another WP Engine site: https://vulcanrealestate.com/

When I test images on our staging version of this site (right click and save image) I see they are webp. But the live site images are not.

When setting up this plugin there was some message about our server not supporting server-based compression, and to use cloud-based instead, but not clear why it isn’t serving the webp images that were generated.

Alright, trying that.

For the record I think that’s an unintuitive way of controlling this feature.

You have an option called “digest”. The language for that option suggests this will assemble all notifications into a digest, rather than getting every single notification.

Further, there is no indication on the Lockouts screen that unchecking that option will still include lockout counts in the digest.

At the very least you should update the instructions in the settings screens to make this more clear.

Ideally though, enabling “digest” should enable “digest” – for all settings.

I do want the lockout notifications, just not as they happen. Will I still get them in the digest?

This happened again a few days ago. We asked the client and they did not update a large number of records.

Can you think of what might cause the plugin to not restart once it’s in a failed state? This is the bigger problem – not why it fails but why it won’t restart after a failure.

Any thoughts on where we might add logging to understand why it isn’t restarting? Or, ideas for a way to kickstart it automatically once it’s in a failed state?

Thank you!

OK, we figured out what’s causing object_sync_for_salesforce_pull_check_records to fail.

We had some logging in our function that runs on object_sync_for_salesforce_pull_object_allowed and apparently that is causing this timeout at 300 seconds and causing the job to be stuck in a failed state.

We commented this out and the problem is fixed. However this leaves us wondering WHY this function caused the problem.

We think it may have to do with our client having updated many records in Salesforce. This caused the function to have to log many entries at once, and that somehow exceeded a limit.

The log function we were calling executed on each iteration of object_sync_for_salesforce_pull_object_allowed:

custom_debug(array(‘mapping’ => $salesforce_mapping[‘name’], ‘object’ => $object), _FILE_, _LINE_);

This logs the name of the object type we’re mapping, the object and the current file and line number.

A lot of items ran through this function, so perhaps it’s just the sheer number of iterations that is choking it.

Any thoughts? Ring any bells?

That does appear to be a good way to trigger it to restart, thank you.

We did discover some PHP errors and cleaned them up, including one fatal one.

Now we can update the frequency and that triggers a sync. The sync appears to pull all modified SF contact records, but it’s not pulling another type of record (experiences) that it normally pulls successfully. At first we thought there were just a lot of accumulated contact records to pull and once it got through those it would move on to experiences, but we’re caught up and just pulling a couple of contacts per sync, but it still ends up “failed” in Scheduled Actions and never pulls experiences. We’ve deliberately modified experiences to force a sync and they don’t sync.

And, once it’s marked failed it doesn’t seem to run again automatically. It stays “failed” until we trigger it again by updating the schedule.

Nothing meaningful now in PHP logs. No evidence of failures in the WP Logs custom post type. No mapping errors.

The “failed” entries always include this in the log:
action marked as failed after 300 seconds. Unknown error occurred. Check server, PHP and database error logs to diagnose cause.

Is it normal once a scheduled action fails for it to remain in a failed state and not become active/pending again? Doesn’t seem like it would/should but we’re running out of ideas.

Thank you!

Following

OK – thanks for the enlightenment. We’ll see what we can do.

We are finding something interesting happening with one SF user synced to two WP users. Actually could be happening with one-to-one as well, haven’t been testing that.

Here are our two users:

WP ID 100
[email protected]
Bob Dobbolina

WP ID 101
[email protected]
Bob Snobbolina

Our Salesforce contact has:

WordPress ID: 101
Home email: [email protected]
Work email: [email protected]
Preferred email: Home
Bob Snobbolina

Let’s say we edit our WP user emails directly in the WP database so we don’t force an update:

[email protected]
[email protected]

Now we go into Salesforce and change the last name to Krobbolina.

We look at WordPress and see

WP ID 100
[email protected]
Bob Krobbolina

WP ID 101
[email protected]
Bob Krobbolina

Great – the last name was updated in both records as expected, and the emails were left alone – not expected but nice, since we didn’t change the email in Salesforce.

However when we go back to Salesforce we see:

WordPress ID: 101
Home email: [email protected]
Work email: [email protected]
Preferred email: Home

So my preferred email (Home) has been updated with the email from the WP user whose ID is found in this Salesforce contact (101).

It seems like a push is being triggered after a pull. I know we don’t do a pull after a push because you built in a rest period to avoid update loops. Is there not a similar rest period between a pull and a push?

Well, you’re going to have to wait to find out. We’re going to export our bad users and provide a spreadsheet to our Salesforce person who will run some magic on her end to clean them out. She’s willing, and then we don’t have to wonder ??

I see. You’re consolidating emails into a string and matching user email against that, it looks like.

If you update the user in Salesforce, what does it do with emails when pulling into WordPress? In our case we have a Preferred Email setting (that may be standard SF – we don’t know SF well) which identifies which email is a given contact’s preferred email. But whether we use that or map a specific email field, it seems like both WP users would be set to the same email address when updating Salesforce. Except I don’t think WP likes that, does it? Do you have a way for handling that?

Sorry for not getting back sooner on this. It’s been sitting in my inbox. It looks like at present we do not have any (more) rows with duplicate SF and WP IDs. We cleaned them up and they have stayed cleaned up so I think this was fallout from a previous cleanup process. Problem solved, or never existed in the first place ??

Unfortunately we have uninstalled it on this site so we could move ahead. If we run across it again though I will give you more info.