Running static analysis (phpcf) against Webform 3.x yields these two errors:

7.0 | /webform/i../webform.export.inc:99 | method_name | Method name webform_exporter_delimited:webform_exporter_delimited (@php4_constructors) is deprecated.

7.0 | /web../in../webform.export.inc:159 | method_name | Method name webform_exporter_excel:webform_exporter_excel (@php4_constructors) is deprecated.

Fix is to rename the constructors to __construct.

This has already been done in the 7.x-4.x branch.

This issue is to do the same in the 7.x-3.x branch for those users not ready to upgrade to Webform 4.x, but who are being forced to upgrade to PHP 7 due to PHP 5.6 EOL.

Comments

josephr5000 created an issue. See original summary.

josephr5000’s picture

Here's a patch.

josephr5000’s picture

Status: Active » Needs review
josephr5000’s picture

Oops, missed a parent:: constructor reference. Here's an updated patch.

josephr5000’s picture

liam morland’s picture

Webform 3 receives critical bug fixes only. If the WF3 community gets this to RTBC, I will commit it.

calebtr’s picture

Status: Needs review » Reviewed & tested by the community
Related issues: +#2938667: Deprecated Function php debug messages

The patch applies, fixes the "deprecated" messages and doesn't break any other stuff.

I note there is a nearly identical solution posted in a related issue (https://www.drupal.org/project/webform/issues/2938667#comment-12988014) - which is what makes me RTBC this.

Is hiding a bunch of error messages "critical" enough? If not, I am okay with closing this issue instead.

calebtr’s picture

Status: Reviewed & tested by the community » Needs review

Rethinking this. It is all fine for Webform to update its own constructors, but what about making them backwards-compatible for contrib and custom modules that might have extended these export handlers?

We could create constructors that just call the old constructors as regular old public methods. It's not pretty, but it suppresses the warnings and supports legacy code.

  public function __construct($options) {
    $this->webform_exporter_excel($options);
  }
liam morland’s picture

That sounds reasonable to me.

caschbre’s picture

StatusFileSize
new738 bytes

Here's a patch to match the latest security release.

I took the patch from #4 but implemented as noted in #8.

liam morland’s picture

Thanks for the patch. I think it would be better if they were the other way around, that is, the __construct() methods contain the actual function and the old function names are wrappers with @deprecated comments.

mradcliffe’s picture

I think this is what you're looking for @Liam Morland.

liam morland’s picture

Yes, that is the idea. We just need someone else to review and test.

dasginganinja’s picture

Status: Needs review » Reviewed & tested by the community

We are now using this at Lehigh University and it is in place for ~120 sites without issues.

liam morland’s picture

Status: Reviewed & tested by the community » Fixed

Thanks everyone.

Status: Fixed » Closed (fixed)

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