Hi there!
Ubuntu 18.04, tripal v3.0 (last release). php7.2.10
when publishing gene (following the citrus example)
I got warning like here: https://www.drupal.org/project/date/issues/2843367. I applied this patch:
2843367-php71-string-offset-26.patch
it seemed that removed the warnings despite the patch being for 7.1 for what I understood.
When publishing mRNA I got this one

is there a fix for that one? (I couldnt find it).
Thanks in advance!
here are the warnings on my site
(tripal 3, php 7.1, OSX)
Warning: Illegal string offset 'value' in date_combo_element_process() (line 295 of /Users/bc/tripal/sites/all/modules/date/date_elements.inc).
Warning: Cannot assign an empty string to a string offset in date_combo_element_process() (line 295 of /Users/bc/tripal/sites/all/modules/date/date_elements.inc).
Warning: Illegal string offset 'value' in date_local_date() (line 145 of /Users/bc/tripal/sites/all/modules/date/date_elements.inc).
Notice: Uninitialized string offset: 0 in date_local_date() (line 145 of /Users/bc/tripal/sites/all/modules/date/date_elements.inc).
Warning: Illegal string offset 'value' in date_combo_element_process() (line 298 of /Users/bc/tripal/sites/all/modules/date/date_elements.inc).
Warning: Cannot assign an empty string to a string offset in date_combo_element_process() (line 298 of /Users/bc/tripal/sites/all/modules/date/date_elements.inc).
Warning: implode(): Invalid arguments passed in date_limit_format() (line 2276 of /Users/bc/tripal/sites/all/modules/date/date_api/date_api.module).
Warning: Illegal string offset 'value' in date_combo_element_process() (line 295 of /Users/bc/tripal/sites/all/modules/date/date_elements.inc).
Warning: Cannot assign an empty string to a string offset in date_combo_element_process() (line 295 of /Users/bc/tripal/sites/all/modules/date/date_elements.inc).
Warning: Illegal string offset 'value' in date_local_date() (line 145 of /Users/bc/tripal/sites/all/modules/date/date_elements.inc).
Notice: Uninitialized string offset: 0 in date_local_date() (line 145 of /Users/bc/tripal/sites/all/modules/date/date_elements.inc).
Warning: Illegal string offset 'value' in date_combo_element_process() (line 298 of /Users/bc/tripal/sites/all/modules/date/date_elements.inc).
Warning: Cannot assign an empty string to a string offset in date_combo_element_process() (line 298 of /Users/bc/tripal/sites/all/modules/date/date_elements.inc).
Warning: implode(): Invalid arguments passed in date_limit_format() (line 2276 of /Users/bc/tripal/sites/all/modules/date/date_api/date_api.module).
Update: I'm reaosnably certain this is from null values in the filters for fields that are date related.
ie:

Looking at these fields, i woudnt even know what sort of values to input to filter by unless i looked in the db.
Furthermore, supplying strings that are stored in my db for these fields (2018-10-24 13:37:16.006814 for example) doesnt resolve these errors.
whats curious about this, is these date fields are configured for the bundle to use a select list, not a text field:

So i wonder if the fields arent getting loaded properly here.
So i can resolve these errors by just skipping the validation for the date fields, by adding this check to the start of the field loop building the filters:
if ($field_name == 'local__time_accessioned' || $field_name == 'local__time_last_modified' ){
continue;
}
Anyone have input? Does it make sense to filter by date? It might, even though the timestamp is down to the second. Looks like the callback for these date fields is date_field_widget_form while for the others its tripal_field_widget, which makes sense because the date field is a core field....
Even though I can see some cases where you may want to filter by date, I think we should simply remove these filters from the publish form. Thoughts?
I'm ok with that. However, I wouldnt underestimate the importance of filtering by date. You might not want to publish all your genes, but only the genes you imported in the past 3 days.
I just submitted a PR along the same lines suggested by @bradfordcondon. The main difference is that I skipped by field type in order to ensure all datetime fields are skipped.
If this issue has been bugging you, please go review PR #1018