Answers.Body: <p>I solved the issue with the help of xurizaemon on the Mattermost chat channel.</p>
  
  <p>The script was failing because it was trying to delete a membership that looked like it was already deleted.</p>
  
  <p>Hints below:</p>
  
  <blockquote>
    <p>so "call to member function delete() on null" means that CiviCRM
    expected there to be an object and called a method on it - but the
    object didn't exist</p>
    
    <p>i'd guess that
    here(<a href="https://github.com/civicrm/civicrm-core/blob/master/CRM/Member/BAO/Membership.php#L631" rel="nofollow noreferrer">https://github.com/civicrm/civicrm-core/blob/master/CRM/Member/BAO/Membership.php#L631</a>)
    Civi tried to fetch a membership</p>
    
    <p>then
    here(<a href="https://github.com/civicrm/civicrm-core/blob/master/CRM/Member/BAO/Membership.php#L665" rel="nofollow noreferrer">https://github.com/civicrm/civicrm-core/blob/master/CRM/Member/BAO/Membership.php#L665</a>)
    Civi tried to delete the membership</p>
    
    <p>but it didn't look to see if the first thing failed - and so when it
    tries to call delete on null, it falls over.</p>
    
    <p>IMO it makes sense to inspect the result of line 631 before it treats
    it as an object</p>
    
    <p>ie if ($membership = $memberships[$membershipId]) { /* do all the
    stuff with $membership */ }</p>
    
    <p>or (easier to read) if (!$membership = $memberships[$membershipId]) {
    /* bail out / throw exception */ }</p>
  </blockquote>
  
  <p>So I downloaded a DB dump to a dev environment. Checked the error was still there.</p>
  
  <p>Then ran the task from the scheduled tasks page. With a vardump in the membership.php script just after the lines noted above.</p>
  
  <p>var_dump($membership);</p>
  
  <p>and then</p>
  
  <p>var_dump($membershipID);</p>
  
  <p>The memberships in the dump were both linked to the same parent membership, so I deleted that parent membership and recreated it from scratch.</p>
  
  <p>Membership scheduled task is now running as usual.</p>
  
  <p>I think the db may have been corrupted a bit on a recent server move.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-06-19T12:44:04.400Z
Answers.Text: We fixed this through this process but it since came back after new memberships. Did this happen to you? Any ideas on fixing this? Thanks
Answers.UserDisplayName: Sohal Khatwani
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-27T05:34:03.790Z
Answers.LastActivityDate: 2017-06-27T05:34:03.790Z
Answers.UserDisplayName: joewickert
Body: <p>We're running Civicrm 4.7.11, Drupal 7.56 on Cpanel.</p>
  
  <p>I'm running cron via a custom php script that calls the url as per the civicrm cookbook.</p>
  
  <p>All the jobs seem to get called except "Update Membership Statuses and Send Renewal Reminders" which fails with:</p>
  
  <pre><code>PHP Fatal error:  Call to a member function delete() on null in /home/sitename/public_html/sites/all/modules/civicrm/CRM/Member/BAO/Membership.php on line 659
  </code></pre>
  
  <p>Same error happens when running from drush, and when trying to execute manually via admin page I get a WSOD 500 error, which i guess is the same problem.</p>
  
  <p>The issue seems to have occurred when moving to a new cpanel server which is using easyapache PHP instead of Cloudlinux.</p>
  
  <p>Any ideas? PHP error? Civicrm? Drupal?</p>
  
  <p>I've been holding off updating Civicrm due to a Leaflet maps issue with drupal.</p>
  
  <p>Thanks
  Joe</p>
  
Tags: <drupal><civimember><cron>
Title: Cron failing on Update Membership Statuses and Send Renewal Reminders
ThreadText: # Cron failing on Update Membership Statuses and Send Renewal Reminders
  
  (Asked by: username_0 on 2017-06-27)
  
  We're running Civicrm 4.7.11, Drupal 7.56 on Cpanel.
  
  I'm running cron via a custom php script that calls the url as per the civicrm cookbook.
  
  All the jobs seem to get called except "Update Membership Statuses and Send Renewal Reminders" which fails with:
  
  ```
  PHP Fatal error:  Call to a member function delete() on null in /home/sitename/public_html/sites/all/modules/civicrm/CRM/Member/BAO/Membership.php on line 659
  
  ```
  
  Same error happens when running from drush, and when trying to execute manually via admin page I get a WSOD 500 error, which i guess is the same problem.
  
  The issue seems to have occurred when moving to a new cpanel server which is using easyapache PHP instead of Cloudlinux.
  
  Any ideas? PHP error? Civicrm? Drupal?
  
  I've been holding off updating Civicrm due to a Leaflet maps issue with drupal.
  
  Thanks
  Joe
  
  **Tags:** drupal, civimember, cron
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2017-06-27. Score: 2
  
  I solved the issue with the help of xurizaemon on the Mattermost chat channel.
  
  The script was failing because it was trying to delete a membership that looked like it was already deleted.
  
  Hints below:
  
  > so "call to member function delete() on null" means that CiviCRM
  > expected there to be an object and called a method on it - but the
  > object didn't exist
  >
  > i'd guess that
  > here(<https://github.com/civicrm/civicrm-core/blob/master/CRM/Member/BAO/Membership.php#L631>)
  > Civi tried to fetch a membership
  >
  > then
  > here(<https://github.com/civicrm/civicrm-core/blob/master/CRM/Member/BAO/Membership.php#L665>)
  > Civi tried to delete the membership
  >
  > but it didn't look to see if the first thing failed - and so when it
  > tries to call delete on null, it falls over.
  >
  > IMO it makes sense to inspect the result of line 631 before it treats
  > it as an object
  >
  > ie if ($membership = $memberships[$membershipId]) { /\* do all the
  > stuff with $membership \*/ }
  >
  > or (easier to read) if (!$membership = $memberships[$membershipId]) {
  > /\* bail out / throw exception \*/ }
  
  So I downloaded a DB dump to a dev environment. Checked the error was still there.
  
  Then ran the task from the scheduled tasks page. With a vardump in the membership.php script just after the lines noted above.
  
  var\_dump($membership);
  
  and then
  
  var\_dump($membershipID);
  
  The memberships in the dump were both linked to the same parent membership, so I deleted that parent membership and recreated it from scratch.
  
  Membership scheduled task is now running as usual.
  
  I think the db may have been corrupted a bit on a recent server move.
  
  > **Comments:**
  > **username_1**: We fixed this through this process but it since came back after new memberships. Did this happen to you? Any ideas on fixing this? Thanks  
  
  ---
  
  