Editing a node with an empty date field produces the following:

  • Warning: Illegal string offset 'value' in date_combo_element_process() (line 295 of /htdocs_20161220/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 /htdocs_20161220/sites/all/modules/date/date_elements.inc).
  • Warning: Illegal string offset 'value' in date_local_date() (line 145 of /htdocs_20161220/sites/all/modules/date/date_elements.inc).
  • Notice: Uninitialized string offset: 0 in date_local_date() (line 145 of /htdocs_20161220/sites/all/modules/date/date_elements.inc).
  • Warning: Illegal string offset 'value' in date_combo_element_process() (line 298 of /htdocs_20161220/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 /htdocs_20161220/sites/all/modules/date/date_elements.inc).
  • Warning: Illegal string offset 'value2' in date_combo_element_process() (line 295 of /htdocs_20161220/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 /htdocs_20161220/sites/all/modules/date/date_elements.inc).
  • Warning: Illegal string offset 'value2' in date_local_date() (line 145 of /htdocs_20161220/sites/all/modules/date/date_elements.inc).
  • Notice: Uninitialized string offset: 0 in date_local_date() (line 145 of /htdocs_20161220/sites/all/modules/date/date_elements.inc).
  • Warning: Illegal string offset 'value2' in date_combo_element_process() (line 298 of /htdocs_20161220/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 /htdocs_20161220/sites/all/modules/date/date_elements.inc).

Steps to reproduce:

  1. Add a date field to a content type.
  2. Create a new node of that type.
  3. Edit the newly created field.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

RemyAroundTown created an issue. See original summary.

RemyAroundTown’s picture

$element['#default_value'] can be an empty string but is used as a multi-level array. In previous versions of PHP this would not throw a warning.

The attached fix checks for an empty element that is not an array and assigns an empty array if required.

RemyAroundTown’s picture

Status: Active » Needs review
RemyAroundTown’s picture

And as soon as I queue the test I realize it won't pass in php 5.3 due to my use of []. Here's a more backwards compatible patch.

Status: Needs review » Needs work

The last submitted patch, 4: 2843367-php71-string-offset-2.patch, failed testing.

glynster’s picture

I can confirm this patch does resolve the issue for me using php7.1. I am not sure what needs to be adjusted to get this to pass. +1 from me regardless. RTBC

RemyAroundTown’s picture

Status: Needs work » Reviewed & tested by the community

It looks like the module itself is failing tests, so that might be another issue that should be cleared up. I'm going to bump the status of this one.

matthiasm11’s picture

Patch #4 looks fine, thanks.

oadaeh’s picture

Issue summary: View changes

I'm just making it a little easier to scan through the error notices in the summary.

johnzzon’s picture

Patch #4 working fine for me as well.

robertgarrigos’s picture

patch #4 worked for me also.

DamienMcKenna’s picture

Issue tags: -php7.1 +PHP 7.1

I've re-queued the tests, lets see how this does.

DamienMcKenna’s picture

DamienMcKenna’s picture

Assigned: RemyAroundTown » Unassigned
DamienMcKenna’s picture

So the tests still fail with 7.0 and 7.1, would someone care to look at them?

https://www.drupal.org/pift-ci-job/635955

https://www.drupal.org/pift-ci-job/635956

DamienMcKenna’s picture

I opened #2865376 so we can look into PHP 7 issues in general.

oadaeh’s picture

DamienMcKenna’s picture

Liam Morland’s picture

Liam Morland’s picture

Sorry, already linked.

alesr’s picture

I did some debugging and the tests are not failing because of this patch.

The problem is in getting the site content to assertText on.

For example: $this->drupalGet('admin/structure/types/manage/story/fields'); (line 78 in date_tools.test)
The content is empty when returned from CURL.

Running tests without the patch also returns the same fails.

alesr’s picture

I was still getting errors on some specific edit pages.
After a closer look I found out the condition set in patch (with &&) is wrong.

if (empty($element['#default_value']) && !is_array($element['#default_value'])) {...}

If '#default_value' index in $element['#default_value'] is not set, empty($element['#default_value']) with be true and it will go to the next check which is !is_array($element['#default_value']). In this check '#default_value' doesn't exist and will return a notice/error.

Here's a patch that fixes this.
The correct condition should be OR (||).

if (empty($element['#default_value']) || !is_array($element['#default_value'])) {...}

If default_value is empty/not set OR not an array...

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 22: 2843367-php71-string-offset-22.patch, failed testing. View results

alesr’s picture

Status: Needs work » Needs review

As mentioned in #21, the tests are failing even without any patch from this issue so that needs to be addressed outside this issue.
I will set it to "Needs review".

joelpittet’s picture

@alesr, #22 doesn't apply, the tests are showing that, you may not be creating against the 2.x-dev branch?

I'm re-uploading the RTBC'd #4

alesr’s picture

Majdi’s picture

Works for me

szeidler’s picture

Patch #26 is also fixing the issue for me on PHP 7.1. I'm not sure about the testbot, but when running the tests locally there is no difference between the number of passed and failed tests before and after applying the patch. So they seems to be unrelated to this particular issue.

ikeigenwijs’s picture

Related issues: +#2889636: Fix PHP 7 tests

Looks good especially in combination with
https://www.drupal.org/node/2889636

ikeigenwijs’s picture

Status: Needs review » Reviewed & tested by the community

The patch in this tread fixes the problem.
php7 tests are fixed in other issu

DamienMcKenna’s picture

FYI I'm unable to reproduce this error with PHP 7.1.6, but the code makes sense so I still think it should be committed.

DamienMcKenna’s picture

This patch resolved the error for my local testing. +1

Plazik’s picture

The patch from #26 works for me on PHP 7.1.9.

dchatry’s picture

#26 seems to work for me also on 7.1.8

Novitsh’s picture

+1

DamienMcKenna’s picture

The patch in comment #26 works perfectly in my testing with PHP 7.1.6. Thank you.

NancyDru’s picture

Good on 7.1.10.

nanobyt3’s picture

#26 seems to fix the issue.
+1 commit
And provide it with next release of date module.

DamienMcKenna’s picture

Status: Reviewed & tested by the community » Fixed

Committed. Thanks all.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

rjensen’s picture

I'm getting these errors on a fresh install of Drupal 7.59 and Date. PHP 7.1.20

Liam Morland’s picture

What version of date are you running?

tomarnold2’s picture

I'm seeing it, too. Date version 7.x-2.10 (latest).
Illegal string offset 'value2' in date_combo_element_process()

Applying patch 26 seems to have done the trick. Thank you!
Tom

Liam Morland’s picture

The patch is not in 7.x-2.10. You need to run the development snapshot no earlier than revision a2ef952.

botris’s picture

magoomby2’s picture

I can confirm this patch does resolve the issue for me using PHP 7.1 using Drupal 7.59

artem0793’s picture

Liam Morland’s picture

It appears likely that the patch in #48 is actually a better solution. A fix is already committed in #39.

DamienMcKenna’s picture

Status: Closed (fixed) » Needs review

That's a reasonable point, thanks for the patch artem0793. Let's revisit this.

azovsky’s picture

Status: Needs review » Reviewed & tested by the community

The patch in #48 is good! Working!
Thank you!

DamienMcKenna’s picture

Status: Reviewed & tested by the community » Fixed

Committed. Thanks again!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

krak’s picture

This issue starter 2 years ago. Fixed month ago and don't created fixed version? Users must look patch file and fix it in file?
What difficult to create new version with fix?

DamienMcKenna’s picture

Please help us get a stable release out by testing the current -dev version or the latest 7.x-2-11-beta releases. Thank you.

Anonymous’s picture

I don't know what happened since yesterday but today this bug had crawled up from its hole and was pushing error to node add and edit pages with date fields.
Committed patch fixed the error, thanks.

cobenash’s picture

Thanks, Commited work.

oranges13’s picture

The patch in #48 works!

alysaselby’s picture

I can verify that #48 worked with the following:

Date 7.x-2.10
Drupal 7.65
PHP 7.2.16

Liam Morland’s picture

The patch in #48 is already committed. Use 7.x-2.11-beta2 to get it.

oranges13’s picture

Some of us need this bugfix and cannot afford to run regression tests on our production systems! Yes it is committed but not everyone runs dev builds.

mdolnik’s picture

FYI the changes in #48's 2843367-php71-string-offset-47.patch are also present in the patch in Issue: Error messages from date_entity_metadata_struct_getter()

malcolm_p’s picture

7.x-2.11-beta2 has resolved this issue for me as well.

fox mulder’s picture

7.x-2.11-beta2 has resolved this issue for me too.

AdamEvertsson’s picture

Can confirm. 7.x-2.11-beta2 made the errors disappear. Though I can't use it in production due to client agreement. Can this be part of a new stable release? If not, what can we do to make that happen?

FireHawkX’s picture

I just updated 3 modules on my site
(made a backup prior so I'm good), one of the modules was Date,

And now I am getting a wall of errors like the one at the top of this post...
all related to date (Illegal string offset 'value' in date_combo_element_process) line 295 and 298

If this is "CLOSED/fixed" why is it not in the latest update that just got downloaded?

(sorry if this is basic knowledge, i'm still kinda noob with all of this and learning)

I edited the date_elements.inc in notepad++ and replace the line
'#default_value' => isset($items[$delta]) ? $items[$delta] : '',
with
'#default_value' => isset($items[$delta]) ? $items[$delta] : array(),

and everything is fine once again :)

oranges13’s picture

It's in a beta release not in stable which is the version you probably downloaded.

So to fix this you have two options: use the newest beta version (https://www.drupal.org/project/date/releases/7.x-2.11-beta3) to have the patch included, or apply patch in #48 yourself.

goodmuyis’s picture

If you are just coming here:
The Development version released on 23 Oct 2019 fixed the issues

solideogloria’s picture

Keep in mind that the development version has the following issue: #3016390: Change in "All day" end-of-day definition broke existing data