Answers.Body: <p>Proper define of the array will sort you out, Please check out this <a href="https://stackoverflow.com/questions/57614225/fatal-error-uncaught-error-operator-not-supported-for-strings-codazon-the/57614957#57614957">Post</a>, this issue is seen with many places after upgrade php.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-09-21T12:45:52.107Z
Answers.Text: So you are proposing I should edit the code? Not sure that is a good idea, since it seems likely to fail again on the next upgrade.
Answers.UserDisplayName: twowheeler
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-09-22T04:37:00.607Z
Answers.Text: yes, just for the check if it will fix and it is common I have seen other places also, so it will fixed in next CiviCRM updates. Form this check atleast you will able to know the exact cause.
Answers.UserDisplayName: Ranjan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-09-26T01:22:43.963Z
Answers.Text: I decided to poke enough error_log() statements into the conversion functions to see what it was choking on.  There was in fact a saved search that seemed to be corrupted.  It creates a smart group we no longer use.  Rather than try to fix it, I deleted that row from the table, and the corresponding row from the civicrm_group table.  After that the upgrade completed successfully.  This is still all in a test site - I am hoping that there are no unintended consequences of deleting those rows, but will do some more testing before going further.  As of now, nothing seems to be broken.
Answers.UserDisplayName: twowheeler
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-09-20T18:28:50.450Z
Answers.LastActivityDate: 2019-09-20T18:28:50.450Z
Answers.UserDisplayName: Ranjan
Body: <p>Testing an upgrade from 5.13.4 to 5.17.4 on wordpress, I get a fatal error. This is on PHP 7.1.32.</p>
  
  <pre><code>PHP Fatal error:  Uncaught Error: [] operator not supported for strings in /home/dhwpuser/testdomain/wp-content/plugins/civicrm/civicrm/CRM/Upgrade/Incremental/SmartGroups.php:105
  Stack trace:
  #0 /home/dhwpuser/testdomain/wp-content/plugins/civicrm/civicrm/CRM/Upgrade/Incremental/SmartGroups.php(48): CRM_Upgrade_Incremental_SmartGroups-&gt;datePickerConversion(Array)
  #1 /home/dhwpuser/testdomain/wp-content/plugins/civicrm/civicrm/CRM/Upgrade/Incremental/Base.php(233): CRM_Upgrade_Incremental_SmartGroups-&gt;updateGroups(Array)
  #2 /home/dhwpuser/testdomain/wp-content/plugins/civicrm/civicrm/CRM/Queue/Task.php(88): CRM_Upgrade_Incremental_Base::updateSmartGroups(Object(CRM_Queue_TaskContext), Array)
  #3 /home/dhwpuser/testdomain/wp-content/plugins/civicrm/civicrm/CRM/Queue/Runner.php(217): CRM_Queue_Task-&gt;run(Object(CRM_Queue_TaskContext))
  #4 /home/dhwpuser/testdomain/wp-content/plugins/civicrm/civicrm/CRM/Queue/Page/AJAX.php(52): CRM_Queue_Runner-&gt;runNext(true)
  #5 /home/dhwpuser/testdomain/wp-content/plugins/civicrm/civicrm/CRM/Queue/ in /home/dhwpuser/testdomain/wp-content/plugins/civicrm/civicrm/CRM/Upgrade/Incremental/SmartGroups.php on line 105
  </code></pre>
  
  <p>This appears to be a well known issue with PHP 7.1. See for example <a href="https://stackoverflow.com/questions/5879675/problem-with-fatal-error-operator-not-supported-for-strings-in">this issue</a>.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-09-19T22:16:10.587Z
Comments.Text: can you check if cli and apache/nginx are using same php version?
Comments.UserDisplayName: Pradeep Nayak
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-09-19T22:34:34.290Z
Comments.Text: Yes same version.
Comments.UserDisplayName: twowheeler
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-09-19T23:20:55.393Z
Comments.Text: did this happen on upgrade?  I just ran an upgrade from 5.13.5 to 5.17.4  WP 5.3.2  Apache 2.4 and php 7.1.32 and did not hit any issues.
Comments.UserDisplayName: Kevin Cristiano
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-09-20T00:45:20.163Z
Comments.Text: It might not be php version-related, it might be something about some smart groups you have that are different than what the upgrade is expecting. It's hard to say if the upgrade should be expecting them and doesn't handle them, or whether there's something off about the smart group. It's expecting to see the smart group definition stored as an array, but it's getting fed something else. Check any smart groups that use date fields, which is what the failing upgrade is about.
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-09-20T02:04:59.017Z
Comments.Text: @KevinCristiano, yes I ran the upgrade twice, after reloading the DB from backup, and got the same result above both times.
Comments.UserDisplayName: twowheeler
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-09-20T02:05:33.550Z
Comments.Text: @Demerit I take your point, it may be due to weird data in our system that the update code does not anticipate.  I will look at our smart groups and see if anything looks odd, but then what?  Do I have to delete those smart groups before the update?
Comments.UserDisplayName: twowheeler
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-09-20T02:30:31.963Z
Comments.Text: A quickie to try is something like looking in the database directly `SELECT id, form_values FROM civicrm_saved_search WHERE LEFT(form_values,1) <> 'a';`. If any results come up then that might be the culprit - compare the id field to the group ids you have listed on the manage groups page in Civi. EDIT: I see recent versions of civi don't show the id anymore on that page. Hover over the Settings link on the right and look at the id= part in the url and that's the id.
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-09-21T12:50:38.857Z
Comments.Text: Thanks for all the comments.  @Demerit that query produced no results.  I have 47 records in civicrm_saved_search so I dumped the contents to a file.  I see they are all json encoded queries, but again I'm not sure what I am looking for.
Comments.UserDisplayName: twowheeler
Tags: <wordpress><upgrade><php7>
Title: Upgrade to civicrm 5.17.4 fails with PHP 7.1 Uncaught Error: [] operator not supported for strings
ThreadText: # Upgrade to civicrm 5.17.4 fails with PHP 7.1 Uncaught Error: [] operator not supported for strings
  
  (Asked by: username_0 on 2019-09-19)
  
  Testing an upgrade from 5.13.4 to 5.17.4 on wordpress, I get a fatal error. This is on PHP 7.1.32.
  PHP Fatal error:  Uncaught Error: [] operator not supported for strings in /home/dhwpuser/testdomain/wp-content/plugins/civicrm/civicrm/CRM/Upgrade/Incremental/SmartGroups.php:105
  Stack trace:
  #0 /home/dhwpuser/testdomain/wp-content/plugins/civicrm/civicrm/CRM/Upgrade/Incremental/SmartGroups.php(48): CRM_Upgrade_Incremental_SmartGroups->datePickerConversion(Array)
  #1 /home/dhwpuser/testdomain/wp-content/plugins/civicrm/civicrm/CRM/Upgrade/Incremental/Base.php(233): CRM_Upgrade_Incremental_SmartGroups->updateGroups(Array)
  #2 /home/dhwpuser/testdomain/wp-content/plugins/civicrm/civicrm/CRM/Queue/Task.php(88): CRM_Upgrade_Incremental_Base::updateSmartGroups(Object(CRM_Queue_TaskContext), Array)
  #3 /home/dhwpuser/testdomain/wp-content/plugins/civicrm/civicrm/CRM/Queue/Runner.php(217): CRM_Queue_Task->run(Object(CRM_Queue_TaskContext))
  #4 /home/dhwpuser/testdomain/wp-content/plugins/civicrm/civicrm/CRM/Queue/Page/AJAX.php(52): CRM_Queue_Runner->runNext(true)
  #5 /home/dhwpuser/testdomain/wp-content/plugins/civicrm/civicrm/CRM/Queue/ in /home/dhwpuser/testdomain/wp-content/plugins/civicrm/civicrm/CRM/Upgrade/Incremental/SmartGroups.php on line 105
  
  This appears to be a well known issue with PHP 7.1. See for example this issue.
  
  **Tags:** wordpress, upgrade, php7
  
  > **Comments:**
  > **username_1**: can you check if cli and apache/nginx are using same php version?  
  > **username_0**: Yes same version.  
  > **username_2**: did this happen on upgrade?  I just ran an upgrade from 5.13.5 to 5.17.4  WP 5.3.2  Apache 2.4 and php 7.1.32 and did not hit any issues.  
  > **username_3**: It might not be php version-related, it might be something about some smart groups you have that are different than what the upgrade is expecting. It's hard to say if the upgrade should be expecting them and doesn't handle them, or whether there's something off about the smart group. It's expecting to see the smart group definition stored as an array, but it's getting fed something else. Check any smart groups that use date fields, which is what the failing upgrade is about.  
  > **username_0**: @KevinCristiano, yes I ran the upgrade twice, after reloading the DB from backup, and got the same result above both times.  
  > **username_0**: @username_3 I take your point, it may be due to weird data in our system that the update code does not anticipate.  I will look at our smart groups and see if anything looks odd, but then what?  Do I have to delete those smart groups before the update?  
  > **username_3**: A quickie to try is something like looking in the database directly `SELECT id, form_values FROM civicrm_saved_search WHERE LEFT(form_values,1) <> 'a';`. If any results come up then that might be the culprit - compare the id field to the group ids you have listed on the manage groups page in Civi. EDIT: I see recent versions of civi don't show the id anymore on that page. Hover over the Settings link on the right and look at the id= part in the url and that's the id.  
  > **username_0**: Thanks for all the comments.  @username_3 that query produced no results.  I have 47 records in civicrm_saved_search so I dumped the contents to a file.  I see they are all json encoded queries, but again I'm not sure what I am looking for.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_4 on 2019-09-20. Score: 0
  
  Proper define of the array will sort you out, Please check out this [Post](https://stackoverflow.com/questions/57614225/fatal-error-uncaught-error-operator-not-supported-for-strings-codazon-the/57614957#57614957), this issue is seen with many places after upgrade php.
  
  > **Comments:**
  > **username_0**: So you are proposing I should edit the code? Not sure that is a good idea, since it seems likely to fail again on the next upgrade.  
  > **username_4**: yes, just for the check if it will fix and it is common I have seen other places also, so it will fixed in next CiviCRM updates. Form this check atleast you will able to know the exact cause.  
  > **username_0**: I decided to poke enough error_log() statements into the conversion functions to see what it was choking on.  There was in fact a saved search that seemed to be corrupted.  It creates a smart group we no longer use.  Rather than try to fix it, I deleted that row from the table, and the corresponding row from the civicrm_group table.  After that the upgrade completed successfully.  This is still all in a test site - I am hoping that there are no unintended consequences of deleting those rows, but will do some more testing before going further.  As of now, nothing seems to be broken.  
  
  ---
  
  