Backend Crashing after update today

Please check your server’s error logs and report what any errors say.

Hi. I’m experiencing the exact same issue. Update from 1.7.0 to 1.8.7 makes the backend of WordPress crash. Front end looks fine. As soon as I extract the backup ZIP of v1.7.0, the backend works great. Were you able to determine any potential fixes? Thank you!

@kipperblakeley I’d love to see some server error logs to understand what exactly is happening. Without that, there’s not much we can offer.

Hi John –?sorry I never got back to you on this. The plugin began working when I re-installed the old version. We had two instances again where the connection to Salesforce got knocked out –?no data passed from Salesforce to our website (displayed using NinjaForms). As soon as I deactivated the plugin, NinjaForms worked again. The first time this happened, in September, the issue resolved itself within 2-3 hours.

In December it happened again, but this time the issue persisted for several days. I couldn’t even access the plugin via WordPress –?every time I clicked on Settings/Salesforce, I would get a blank page. When I tried to reinstall the plugin, I couldn’t get it working again, until it again magically resolved itself and all data from Salesforce showed up a few days later.

I’m wondering if we may have run against the Salesforce API request limit? It’s a simple RSVP page, which has a URL parameter contact_id that pulls the data from Salesforce (name of person, which events they’ve been invited to, dietary preferences, etc.) At most, 100 people might be viewing their pages at one time, with maybe 200-300 max during a 24 hour period. As I understand it, each webpage with a URL parameter that pulls to Salesforce counts as just one API call. But maybe we’re running up the concurrent limit of (I believe) 25 API calls at once.

Would running up again the API limit knock the ObjectSync plugin offline like it did? Have you ever had this experience before? Everything is working fine now and, unfortunately no matter how hard I try, I can’t “crash” the system and replicate what happened (to gain access to useful info from the debug logs).

Any help you can provide would be greatly appreciated. Thank you!

• This reply was modified 5 years, 1 month ago by kipperblakeley. Reason: differentiation between 24-hour API limit and concurrent limit

Sorry, Jonathan (misspelled your name)

@kipperblakeley I think you should check for PHP error logs on your server. If you’re seeing a blank page, there should be PHP errors. To be clear, I don’t mean debug logs for this plugin (although those are also very helpful); I mean error logs on the server itself.

I don’t know if you might be running into Salesforce API limits. It’s possible. But the plugin does cache results from every API call it runs.

In any case I am not sure I would do what you’re talking about that way. What you should probably do is map the contacts to WordPress users, and build a page that loads the metadata from the WordPress user object instead of loading it directly from Salesforce. The Salesforce API is not performant enough to load stuff directly like that.

To be clear, whether that is related to the issue you are seeing is a different question. It may not be at all.

Thank you so much for your feedback. Some of the developers I’ve reached out to have suggested syncing Salesforce periodically to a database residing on our server. That would reduce the number of API calls during the 24 hours (currently about 500 of the 25’000 we’re allowed, so I think you’re right), and would reduce the number of concurrent calls.

Although, if I understand you correctly, if the plugin does cashe results from every API call it runs, then it in essence pulls that data from Salesforce for a split second and closes the connection (unless the person refreshes the page). So we shouldn’t be running up against concurrent call limits either. Did I understand you correctly?

Below the error log from 9 December 2019 (when our system crashed for several days)

09-Dec-2019 18:38:52 UTC] PHP Warning: require_once(/home/wmadminwm/public_html/wp-content/plugins/object-sync-for-salesforce/vendor/autoload.php): failed to open stream: No such file or directory in /home/wmadminwm/public_html/wp-content/plugins/object-sync-for-salesforce/object-sync-for-salesforce.php on line 212
[09-Dec-2019 18:38:52 UTC] PHP Fatal error: require_once(): Failed opening required ‘/home/wmadminwm/public_html/wp-content/plugins/object-sync-for-salesforce/vendor/autoload.php’ (include_path=’.:/opt/alt/php71/usr/share/pear’) in /home/wmadminwm/public_html/wp-content/plugins/object-sync-for-salesforce/object-sync-for-salesforce.php on line 212
[09-Dec-2019 18:39:18 UTC] PHP Warning: require(/home/wmadminwm/public_html/wp-includes/version.php): failed to open stream: No such file or directory in /home/wmadminwm/public_html/wp-settings.php on line 24
[09-Dec-2019 18:39:18 UTC] PHP Fatal error: require(): Failed opening required ‘/home/wmadminwm/public_html/wp-includes/version.php’ (include_path=’.:/opt/alt/php71/usr/share/pear’) in /home/wmadminwm/public_html/wp-settings.php on line 24
[09-Dec-2019 18:39:19 UTC] PHP Warning: require(/home/wmadminwm/public_html/wp-includes/version.php): failed to open stream: No such file or directory in /home/wmadminwm/public_html/wp-settings.php on line 24
[09-Dec-2019 18:39:19 UTC] PHP Fatal error: require(): Failed opening required ‘/home/wmadminwm/public_html/wp-includes/version.php’ (include_path=’.:/opt/alt/php71/usr/share/pear’) in /home/wmadminwm/public_html/wp-settings.php on line 24
[09-Dec-2019 20:47:19 UTC] PHP Fatal error: Uncaught Error: Call to undefined function mk_get_body_class() in /home/wmadminwm/public_html/wp-content/themes/jupiter/header.php:21
Stack trace:
#0 /home/wmadminwm/public_html/wp-includes/template.php(722): require_once()
#1 /home/wmadminwm/public_html/wp-includes/template.php(671): load_template(‘/home/wmadminwm…’, true)
#2 /home/wmadminwm/public_html/wp-includes/general-template.php(41): locate_template(Array, true)
#3 /home/wmadminwm/public_html/wp-content/themes/jupiter/404.php(8): get_header()
#4 /home/wmadminwm/public_html/wp-includes/template-loader.php(98): include(‘/home/wmadminwm…’)
#5 /home/wmadminwm/public_html/wp-blog-header.php(19): require_once(‘/home/wmadminwm…’)
#6 /home/wmadminwm/public_html/index.php(17): require(‘/home/wmadminwm…’)
#7 {main}
thrown in /home/wmadminwm/public_html/wp-content/themes/jupiter/header.php on line 21
[09-Dec-2019 20:56:05 UTC] PHP Warning: require(/home/wmadminwm/public_html/wp-includes/version.php): failed to open stream: No such file or directory in /home/wmadminwm/public_html/wp-settings.php on line 24
[09-Dec-2019 20:56:05 UTC] PHP Fatal error: require(): Failed opening required ‘/home/wmadminwm/public_html/wp-includes/version.php’ (include_path=’.:/opt/alt/php71/usr/share/pear’) in /home/wmadminwm/public_html/wp-settings.php on line 24
[13-Dec-2019 20:32:11 UTC] Array

And here at this link is the PHP error log from 26 September, which knocked us out for about 3 hours. I’ve included the days before and after, so that you can see what the normal error logs looked like.

• This reply was modified 5 years, 1 month ago by kipperblakeley.

There’s a lot going on in those logs, but it looks to me like your database server went down.

I think there are a few possibilities:

1. The plugin’s scheduled tasks are running too often (which is configured in the plugin’s Scheduling tab) and your server can’t handle the load. If you are not actually saving any data in WordPress (which again, I do NOT recommend), though, I don’t see why the schedule would be running at all.
2. You are missing something that the plugin is looking for. For example, line 212 of the main plugin file is mentioned in your logs but that error isn’t what line 212 actually does. Maybe this is because you are running an older version, but I can’t really speak to that?
3. I do see a lot of errors from other plugins and from your theme. There’s potentially something causing conflict because of that, but I don’t know if that is at all related.
4. Again I would not recommend loading data from the Salesforce API directly on every page load. The API often takes a long time to return responses, which is why the plugin tries to offload that stuff onto scheduled tasks. It could be that the server is having trouble because of that.

I am not sure I can help much beyond that.

Also, to the suggestion for storing data from Salesforce in another database, that is basically what this plugin is built to do. It stores data from one Salesforce object into a WordPress object. If you aren’t doing that with it, honestly I would recommend using another plugin.

Hi Jonathan. This is a huge help. Thank you so much for all these thoughts!

I will look into then creating a database on our website, which will sync with Salesforce via ObjectSync.

Thank you again for all of your help!!!

No, I would say don’t do that. This plugin is not built for that. Use another plugin if that is what you want to do.

To be clear, this plugin is meant to work like this:

1. You create a fieldmap that allows a WordPress object and a Salesforce object to share data, either in both directions or from one system to the other.
2. It runs at intervals with its scheduled task, and saves the data.

It definitely can save data from Salesforce into the database that powers WordPress.

But if you want to build onto a separate database, this plugin is not helpful for that.

Thank you for the clarification. Yes, we would like to use the existing database (sorry, not create a new one). The developer we used had us map each field manually within the functions.php file, because we are using NinjaForms. Is there a way to use the mapping functionality of the plugin to match Salesforce fields to the NinjaForm fields? Or is that the separate database that you mention, which we should not use the plugin to connect to? Sorry if this is a really stupid question.