Answers.Body: <p>We encountered the same problem. Whenever cloning the system (CiviCRM 5.65.1) from production to staging, all smart groups were non-functional. Instead, all contacts became members of all smart groups.</p>
  <p>The Drupal protocol showed this warning:</p>
  <blockquote>
  <p>Warning: Invalid argument supplied for foreach() in CRM_Contact_BAO_SavedSearch::getFormValues() (line 65 of /xxx/crm.mysite.de/httpdocs/dev/public/sites/all/modules/civicrm/CRM/Contact/BAO/SavedSearch.php).</p>
  </blockquote>
  <p>I found out the reason for this:</p>
  <p>When we clone the production system to staging, we create a dump of the CiviCRM database with mysqldump and then replace every instance of the production URL with the staging URL in this database dump (using sed). This works fine for most tables, but in the table <code>civicrm_saved_search</code> there is a column <code>form_values</code> that stores the SQL call on which a saved search is based on. (The smart groups are based on these saved searches then.) This column <code>form_values</code> contains data in the form of a serialized string, for example:</p>
  <p><code> a:10:{i:0;a:5:{i:0;s:8:&quot;entryURL&quot;;i:1;s:1:&quot;=&quot;;i:2;s:86:&quot;https://crm.mysite.de/civicrm/event/add?action=add&amp;reset=1&amp;template_id=16&amp;is_template=&quot;;i:3;s:1:&quot;0&quot;;i:4;s:1:&quot;0&quot;;}i:1;a:5:{i:0;s:21:&quot;group_search_selected&quot;;i:1;s:1:&quot;=&quot;;i:2;s:5:&quot;group&quot;;i:3;s:1:&quot;0&quot;;i:4;s:1:&quot;0&quot;;}i:2;a:5:{i:0;s:14:&quot;tag_types_text&quot;;i:1;s:1:&quot;=&quot;;i:2;s:12:&quot;Aktivitäten&quot;;i:3;s:1:&quot;0&quot;;i:4;s:1:&quot;0&quot;;}i:3;a:5:{i:0;s:16:&quot;privacy_operator&quot;;i:1;s:1:&quot;=&quot;;i:2;s:2:&quot;OR&quot;;i:3;s:1:&quot;0&quot;;i:4;s:1:&quot;0&quot;;}i:4;a:5:{i:0;s:14:&quot;privacy_toggle&quot;;i:1;s:1:&quot;=&quot;;i:2;s:1:&quot;1&quot;;i:3;s:1:&quot;0&quot;;i:4;s:1:&quot;0&quot;;}i:5;a:5:{i:0;s:18:&quot;membership_type_id&quot;;i:1;s:2:&quot;IN&quot;;i:2;a:6:{i:0;s:1:&quot;1&quot;;i:1;s:1:&quot;2&quot;;i:2;s:1:&quot;3&quot;;i:3;s:1:&quot;7&quot;;i:4;s:1:&quot;8&quot;;i:5;s:1:&quot;9&quot;;}i:3;s:1:&quot;0&quot;;i:4;s:1:&quot;0&quot;;}i:6;a:5:{i:0;s:20:&quot;membership_status_id&quot;;i:1;s:1:&quot;=&quot;;i:2;a:1:{s:2:&quot;IN&quot;;a:4:{i:0;s:1:&quot;1&quot;;i:1;s:1:&quot;2&quot;;i:2;s:1:&quot;3&quot;;i:3;s:1:&quot;5&quot;;}}i:3;s:1:&quot;0&quot;;i:4;s:1:&quot;0&quot;;}i:7;a:5:{i:0;s:11:&quot;member_test&quot;;i:1;s:1:&quot;=&quot;;i:2;s:1:&quot;0&quot;;i:3;s:1:&quot;0&quot;;i:4;s:1:&quot;0&quot;;}i:8;a:5:{i:0;s:8:&quot;operator&quot;;i:1;s:1:&quot;=&quot;;i:2;s:3:&quot;AND&quot;;i:3;s:1:&quot;0&quot;;i:4;s:1:&quot;0&quot;;}i:9;a:5:{i:0;s:14:&quot;component_mode&quot;;i:1;s:1:&quot;=&quot;;i:2;s:1:&quot;1&quot;;i:3;s:1:&quot;0&quot;;i:4;s:1:&quot;0&quot;;}}</code></p>
  <p>When sed now replaces <a href="https://crm.mysite.de" rel="nofollow noreferrer">https://crm.mysite.de</a> with <a href="https://crmtest.mysite.de" rel="nofollow noreferrer">https://crmtest.mysite.de</a>, the format of the serialized string is destroyed, because the value <code>s:86</code> in front of the URL describes the number of characters in the following string, which is not correct anymore after replacing the URL (86 with crm.mysite.de, but 90 with crmtest.mysite.de).</p>
  <p>So if in this example you replace not only the production URL with the staging URL, but also the number of characters of the production URL (complete, with directories) with the number of characters of the staging URL, the smart group is functional again! :) Don't forget to empty the CiviCRM cache before checking if the smart groups are functional again.</p>
  <p>I consider it not best practise though that the CiviCRM code responsable for unserializing this field (public/sites/all/modules/civicrm/CRM/Contact/BAO/SavedSearch.php, line 61) does not check if the unserialize function really returns an array, or just FALSE. It just hands over any result to the rest of the function.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-03-13T11:19:27.013Z
Answers.LastActivityDate: 2024-04-08T12:01:22.420Z
Answers.LastEditDate: 2024-04-08T12:01:22.420Z
Answers.UserDisplayName: emma
Answers.Body: <p>I don't see any such job, nor do I recall such a thing.</p>
  
  <p>But: the contacts that are in smart groups are cached in <code>civicrm_group_contact_cache</code> so you should be able to clear that using the CiviCRM "cleanup caches" option (under Administer -> System settings).</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-02-21T15:37:19.367Z
Answers.LastActivityDate: 2020-02-21T15:37:19.367Z
Answers.UserDisplayName: Alan Dixon
Body: <p>When we clone our production instance to staging, we restore the database with updated host information prior to restoring the database.</p>
  
  <p>Querying a smart group returns all contacts in database, not just those in the smart group. Running the <strong>Rebuild Smart Group Cache</strong> scheduled job does not do anything. </p>
  
  <p>Here Eileen says <a href="https://civicrm.stackexchange.com/questions/31303/how-do-the-rebuild-smart-group-cache-scheduled-job-and-the-smart-group-cache-tim">How do the Rebuild Smart Group Cache scheduled job and the Smart group cache timeout setting interact?</a></p>
  
  <blockquote>
    <p>Note I DO recommend running the job that flushes expired groups by
    scheduled job - just not the one that rebuild them all, even the ones
    you don't really need</p>
  </blockquote>
  
  <p>Where is that job?</p>
  
Tags: <smartgroups>
Title: Smart groups break when database is restored
ThreadText: # Smart groups break when database is restored
  
  (Asked by: username_0 on 2020-02-19)
  
  When we clone our production instance to staging, we restore the database with updated host information prior to restoring the database.
  
  Querying a smart group returns all contacts in database, not just those in the smart group. Running the **Rebuild Smart Group Cache** scheduled job does not do anything.
  
  Here Eileen says [How do the Rebuild Smart Group Cache scheduled job and the Smart group cache timeout setting interact?](https://civicrm.stackexchange.com/questions/31303/how-do-the-rebuild-smart-group-cache-scheduled-job-and-the-smart-group-cache-tim)
  
  > Note I DO recommend running the job that flushes expired groups by
  > scheduled job - just not the one that rebuild them all, even the ones
  > you don't really need
  
  Where is that job?
  
  **Tags:** smartgroups
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2024-03-13. Score: 3
  
  We encountered the same problem. Whenever cloning the system (CiviCRM 5.65.1) from production to staging, all smart groups were non-functional. Instead, all contacts became members of all smart groups.
  
  The Drupal protocol showed this warning:
  
  > Warning: Invalid argument supplied for foreach() in CRM\_Contact\_BAO\_SavedSearch::getFormValues() (line 65 of /xxx/crm.mysite.de/httpdocs/dev/public/sites/all/modules/civicrm/CRM/Contact/BAO/SavedSearch.php).
  
  I found out the reason for this:
  
  When we clone the production system to staging, we create a dump of the CiviCRM database with mysqldump and then replace every instance of the production URL with the staging URL in this database dump (using sed). This works fine for most tables, but in the table `civicrm_saved_search` there is a column `form_values` that stores the SQL call on which a saved search is based on. (The smart groups are based on these saved searches then.) This column `form_values` contains data in the form of a serialized string, for example:
  
  `a:10:{i:0;a:5:{i:0;s:8:"entryURL";i:1;s:1:"=";i:2;s:86:"https://crm.mysite.de/civicrm/event/add?action=add&reset=1&template_id=16&is_template=";i:3;s:1:"0";i:4;s:1:"0";}i:1;a:5:{i:0;s:21:"group_search_selected";i:1;s:1:"=";i:2;s:5:"group";i:3;s:1:"0";i:4;s:1:"0";}i:2;a:5:{i:0;s:14:"tag_types_text";i:1;s:1:"=";i:2;s:12:"Aktivitäten";i:3;s:1:"0";i:4;s:1:"0";}i:3;a:5:{i:0;s:16:"privacy_operator";i:1;s:1:"=";i:2;s:2:"OR";i:3;s:1:"0";i:4;s:1:"0";}i:4;a:5:{i:0;s:14:"privacy_toggle";i:1;s:1:"=";i:2;s:1:"1";i:3;s:1:"0";i:4;s:1:"0";}i:5;a:5:{i:0;s:18:"membership_type_id";i:1;s:2:"IN";i:2;a:6:{i:0;s:1:"1";i:1;s:1:"2";i:2;s:1:"3";i:3;s:1:"7";i:4;s:1:"8";i:5;s:1:"9";}i:3;s:1:"0";i:4;s:1:"0";}i:6;a:5:{i:0;s:20:"membership_status_id";i:1;s:1:"=";i:2;a:1:{s:2:"IN";a:4:{i:0;s:1:"1";i:1;s:1:"2";i:2;s:1:"3";i:3;s:1:"5";}}i:3;s:1:"0";i:4;s:1:"0";}i:7;a:5:{i:0;s:11:"member_test";i:1;s:1:"=";i:2;s:1:"0";i:3;s:1:"0";i:4;s:1:"0";}i:8;a:5:{i:0;s:8:"operator";i:1;s:1:"=";i:2;s:3:"AND";i:3;s:1:"0";i:4;s:1:"0";}i:9;a:5:{i:0;s:14:"component_mode";i:1;s:1:"=";i:2;s:1:"1";i:3;s:1:"0";i:4;s:1:"0";}}`
  
  When sed now replaces <https://crm.mysite.de> with <https://crmtest.mysite.de>, the format of the serialized string is destroyed, because the value `s:86` in front of the URL describes the number of characters in the following string, which is not correct anymore after replacing the URL (86 with crm.mysite.de, but 90 with crmtest.mysite.de).
  
  So if in this example you replace not only the production URL with the staging URL, but also the number of characters of the production URL (complete, with directories) with the number of characters of the staging URL, the smart group is functional again! :) Don't forget to empty the CiviCRM cache before checking if the smart groups are functional again.
  
  I consider it not best practise though that the CiviCRM code responsable for unserializing this field (public/sites/all/modules/civicrm/CRM/Contact/BAO/SavedSearch.php, line 61) does not check if the unserialize function really returns an array, or just FALSE. It just hands over any result to the rest of the function.
  
  
  ---
  
  ### Answer by username_2 on 2020-02-21. Score: 1
  
  I don't see any such job, nor do I recall such a thing.
  
  But: the contacts that are in smart groups are cached in `civicrm_group_contact_cache` so you should be able to clear that using the CiviCRM "cleanup caches" option (under Administer -> System settings).
  
  
  ---
  
  