kipperblakeley

Thank you, Jonathan. I just checked and it looks like things should work (in theory, at least). I’ll give it a go mapping the Salesforce fields to the WP User objects. For some reason I tried this many months ago and couldn’t get it to map, but now it maps (and syncs) with ease.

I’ll let you know how it works out. Thank you once again for your help!

Also, I hate using up so much of your time. Is there anyway to hire you to help me out on this, or should I hire a freelancer to look through and see what the problem might be? You are the expert in this plugin, so I would love to work with you. But let me know if that is against any rules here.

Jonathan, you mentioned line 212 of the code. ” 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?”

Below is the code from the object-sync-for-salesforce.php that was in place at the time of the crash.

211 private function load( $wpdb, $version, $slug, $option_prefix ) {
212 require_once plugin_dir_path( __FILE__ ) . ‘vendor/autoload.php’;
213 }

Any thoughts on why this could be causing this error?

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.

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!!!

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.

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

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?

Sorry, Jonathan (misspelled your name)

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

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!