After enabed moderation of revisions in node type admin form, I got the folloing errors while add a new node:

Warning: Illegal string offset '#tree' in form_builder() (line 1891 in C:\xampp\htdocs\test\includes\form.inc).
Warning: Cannot assign an empty string to a string offset in form_builder() (line 1891 in C:\xampp\htdocs\test\includes\form.inc).
Warning: Illegal string offset '#tree' in form_builder() (line 1911 in C:\xampp\htdocs\test\includes\form.inc).
Warning: Illegal string offset '#parents' in form_builder() (line 1911 in C:\xampp\htdocs\test\includes\form.inc).
Warning: Illegal string offset '#array_parents' in form_builder() (line 1916 in C:\xampp\htdocs\test\includes\form.inc).
Warning: Illegal string offset '#weight' in form_builder() (line 1920 in C:\xampp\htdocs\test\includes\form.inc).
Warning: Illegal string offset '#processed' in form_builder() (line 1802 in C:\xampp\htdocs\test\includes\form.inc).
Warning: Cannot assign an empty string to a string offset in form_builder() (line 1802 in C:\xampp\htdocs\test\includes\form.inc).
Error: Unsupported operand types in form_builder() (line 1812 in C:\xampp\htdocs\test\includes\form.inc).

My PHP version is 7.1.4.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

antims created an issue. See original summary.

agentrickard’s picture

Status: Active » Closed (duplicate)

These are all notices from core.

#2656548: Fully support PHP 7.0 in Drupal 7

jrochate’s picture

Status: Closed (duplicate) » Active

Well, actually I don't think it's core problem.

This error can be solved by setting "Moderate all content from ...." in Workbench Moderation role permissions.

Go to admin/people/permissions, pick users role, and filter for Workbench Moderation permissions.
Then, set one or all of "Moderate all content from ..."

Now you can edit the content without errors.

So, if this get's "fixed" by setting a permission, I don't think it's core's PHP7 incompatibility issue.

Rob Holmes’s picture

Assigned: Unassigned » Rob Holmes

I can confirm that this issue manifests on a site with workbench_moderation rujnning on PHP 7.1.9.

I have a site where a specific role had the permission 'bypass workbench moderation', as soon as that was removed these issues started to appear, ill add more detail later today as I debug.

Strangely the same site, same database etc running on PHP 7.0.15 does not throw the same errors.

Rob Holmes’s picture

Ok i have found the issue.

On line 1011 workbench_moderation.module the following statement results in an empty string "" being assigned for $form['options']['workbench_moderation_state_new'] when there are no available states to transition to.

$form['options']['workbench_moderation_state_new'] = isset($form['revision_information']['workbench_moderation_state_new']) ? $form['revision_information']['workbench_moderation_state_new'] : '';

The form API will later do a += on that form child element on line 1812 of /includes/form.inc

$element += array(
      '#required' => FALSE,
      '#attributes' => array(),
      '#title_display' => 'before',
    );

This causes the subsequent fatal error: Uncaught Error: Unsupported operand types in .......\includes\form.inc on line 1813

$form['options']['workbench_moderation_state_new'] should not actaully exist when only one transition is available as the moderation state is actually stored as a value on line 985 of workbench_moderation.module. i.e.

    // Store the current moderation state
    $form['workbench_moderation_state_new'] = array(
      '#type' => 'value',
      '#value' => $moderation_state
);

The easy fix here is to just make the statement return an empty array instead of an empty string stopping the error occuring. Ill upload the patch shortly.

Rob Holmes’s picture

Patch to change empty string to empty array attached

Ms1991’s picture

Greetings,

I've been having a similar problem since I've updated the PHP to the version 7.1.18. I've applied Rob Holme's patch but the problem still happens everytime I try to edit something. The problem seems to be the same as the one Rob Holme's stated above - something other than an array is being sent to the forms.inc. I've added a breakpoint to the function where the problem is happening and we see that the argument received at that time is not an array but an integer (0). If I do something as stupid as:

if(!is_array($element))
$element = array();

It works fine. This happens on the form_builder function in the form.inc file of the drupal core. Has anyone been through this issue?

Thanks!

Ms1991’s picture

Greetings,

Disregard the last comment. I eventually found out it was related to some other module.

Cheers

akishankar’s picture

Hi Ms1991, Could you please help with your findings. I also happen to face a similar issue with my $form_state components on PHP version 7.1.18. It appears that the $form_state is not being carried from one step to another.
Just to add a note, it works fine on PHP version 7.1.11. I am using webform module but it appears that the issue is around the way forms are being handled.

Rob Holmes’s picture

Assigned: Rob Holmes » Unassigned
bceyssens’s picture

Status: Active » Reviewed & tested by the community

Same issue here. This is definitely a bug in Workbench Moderation and #6 seems like an appropriate solution.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 6: php7_support-12293074-6.patch, failed testing. View results

ccjjmartin’s picture

Status: Needs work » Reviewed & tested by the community
Issue tags: +php7.1, +php71, +PHP 7.1

The patch applies cleanly, passed my functional testing, and passed testbot testing last time around but it looks like the testbot improperly failed it. Queuing tests again.

hhvardan’s picture

Patch works for me. Thanks!

erok415’s picture

Hi there,
Does anyone know if this an issue with Drupal core 7.61?

E

solideogloria’s picture

Issue tags: +Needs reroll
Liam Morland’s picture

Issue tags: -php71
Liam Morland’s picture

Issue tags: -php7.1
dscl’s picture

Issue tags: -Needs reroll

Removing the "Needs reroll" given that the patch has passed the last tests.

joseph.olstad’s picture

Feel free to add me as a co-maintainer.

Please commit, I also have clients still using the 1.x branch (heavily patched) , this patch is clean on both 3.x and 1.x branches.

ALSO, PLEASE ACTIVATE php 7.3.x as the default version of php for commits on both the workbench_moderation 1.x and 3.x branches.

DanielVeza’s picture

Adding another +1 into the void in hopes for this to get committed

joseph.olstad’s picture

I've contacted two of this projects maintainers to get their attention on this issue, if they do not respond in the next 4 weeks, we should escalate.

larowlan’s picture

Assigned: Unassigned » agentrickard

Hi Thanks for contacting me, I don't maintain the 7.x branch - I only worked on/maintain the 8.x branch

I think perhaps @agentrickard is your best bet

larowlan’s picture

Assigned: agentrickard » larowlan

Although the patch is so minor, I think I could do that without stepping on toes, ask for forgiveness not permission etc

larowlan’s picture

Assigned: larowlan » das-peter
Status: Reviewed & tested by the community » Fixed

I added php 7.3 test support https://www.drupal.org/pift-ci-job/1439780 but I didn't make it the default, as I think that is overstepping the mark, as I'm only supposed to work on the D8 branch.

The 1.x branch is unsupported for security reasons, see https://www.drupal.org/node/2824455 - so I didn't backport it

@agentrickard @das-peter I'll leave it to you if you want to make a new release for this, there are about 6 issues committed since the last one.

joseph.olstad’s picture

Version: 7.x-3.0 » 7.x-1.x-dev

Sorry to bug you again, I know it sounds weird, but if you could throw this into the 7.x-1.x branch as well, that'd be great.

the commit should cleanly cherry-pick into the 7.x-1.x branch
git checkout 7.x-1.x
git cherry-pick 541aac7
git push

I just tested it, cleanly applies

see :

[7.x-1.x cf86e6a] Issue #2871962 by Rob Holmes: PHP7 support
 Author: onemanonelaptop <onemanonelaptop@1774034.no-reply.drupal.org>
 Date: Fri Oct 18 11:43:10 2019 +1000
 1 file changed, 1 insertion(+), 1 deletion(-)

Thanks again.

joseph.olstad’s picture

Status: Fixed » Reviewed & tested by the community
larowlan’s picture

The 1.x branch is unsupported for security reasons, see https://www.drupal.org/node/2824455

Committing to it sends the wrong message, I'm not going to do that without OK from das.peter or agentrickard, and even then I don't think it is wise

joseph.olstad’s picture

Version: 7.x-1.x-dev » 7.x-3.x-dev
Status: Reviewed & tested by the community » Fixed

Fair enough, for those using 1.x they mostly have a tonne of patches anyway.

Status: Fixed » Closed (fixed)

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