View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0019193phpList 3 pluginsGeneralpublic20-04-18 09:4303-11-18 08:31
Reportersuela Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Summary0019193: The API does no longer work with newer versions of PHP (eg 7)
DescriptionThe problem was first Identified from "raspberrypi" client.
They were having problems when trying to consume the isListSubscriber request.
They get a 200 OK response but the body only seems to contain the schema, not the actual boolean of if the user appears in the list:

Details on the email.
TagsNo tags attached.

Activities

michiel

21-04-18 20:47

administrator   ~0060454


I tried and it works fine with PHP 5.4 and probably 5.6

but I think it stopped working with PHP 7.

This will be quite involved to try to get to work again, but we can see if that is a priority. For now, I think the best thing to do is to explain to clients that it will not work with PHP7 or higher.

FYI @samtuke

suela

21-04-18 20:54

reporter   ~0060455

I will update the client, but I think we should check into this. Also It would be good to have the clients that are using the API.

michiel

22-04-18 09:52

administrator   ~0060456

I tried updating to a nusoap for PHP7, https://github.com/econea/nusoap

but that didn't work. It's likely that @xheni can find out how to fix this.

xheni

22-04-18 15:57

developer   ~0060457

@michiel which version of nusoap do we use right now?

michiel

22-04-18 20:36

administrator   ~0060460

I think on the server, we use the latest. But it doesn't matter what's on the server. What we need is to fix the client to work with PHP7.

suela

27-04-18 08:58

reporter   ~0060481

The client said that they may leave if we don't find a solution for this.

suela

27-04-18 11:40

reporter   ~0060482

FYI @samtuke

samtuke

27-04-18 12:04

manager   ~0060484

@xheni The client side library is quite simple. Do you think you can find the cause of the problem? If it is due to depreciated functions then simply enabling PHP error reporting should give a detailed explanation.

xheni

27-04-18 22:16

developer   ~0060488

Last edited: 27-04-18 22:30

View 2 revisions

 @michiel I tried it with php5.6 and it's not working. On php7: The var_dump is giving me a string(1) "1" if it's true and string(0) " " if false, it returns null.
On php5.6 : it's bool(false) but it's returning null value .

michiel

27-04-18 22:31

administrator   ~0060489

Yes, I think it will only work on PHP5.4 or something.

When I run from cedar, it works fine

PHP 5.4.45-1~dotdeb+6.1 (cli) (built: Sep 5 2015 00:09:17)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies

suela

29-04-18 10:24

reporter   ~0060494

@michiel @xheni we will need an update for the client by tomorrow, this is pretty urgent to them

michiel

29-04-18 10:40

administrator   ~0060495

For now, you need to tell the client to use PHP5.4

xheni

29-04-18 14:03

developer   ~0060496

I tested this under PHP 7 and PHP 5.6 and it misbehaves in both cases. This is my conclusion after some debugging:

NuSoap converts the SOAP datatypes in function decodeSimple to the PHP datatypes. NuSoap takes the response from the server for this and the current response is:

<?xml version="1.0" encoding="ISO-8859-1"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><ns1:phpListHosted.isListSubscriberResponse xmlns:ns1="http://tempuri.org"><return xsi:type="xsd:bool"></return></ns1:phpListHosted.isListSubscriberResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>%

As you can see the datatype is set to xsd:bool but the decodeSimple function in the nuSoap library accepts only xsd:boolean. (the string after xsd: is passed to this function as $type)

function decodeSimple($value, $type, $typens) {
  // TODO: use the namespace!
  if ((!isset($type)) || $type == 'string' || $type == 'long' || $type == 'unsignedLong') {
     return (string) $value;
  }
  if ($type == 'int' || $type == 'integer' || $type == 'short' || $type == 'byte') {
     return (int) $value;
  }
  if ($type == 'float' || $type == 'double' || $type == 'decimal') {
     return (double) $value;
  }
  if ($type == 'boolean') {
     if (strtolower($value) == 'false' || strtolower($value) == 'f') {
        return false;
     }
     return (boolean) $value;
  }
  if ($type == 'base64' || $type == 'base64Binary') {
     $this->debug('Decode base64 value');
     return base64_decode($value);
  }


Also, the SOAP specs require boolean instead of bool (http://schemas.xmlsoap.org/soap/envelope/).
This is another example of another company using NuSoap server-side. By clicking on the API docs you can see that they use xsd:boolean: https://www.talend.com/TalendRegisterWS/registerws.php

This indicates to me that this is rather a server-side problem. To fix it I’d suggest one of the following approaches:

1. Add a new parsing behavior to the library but that would be a custom patch and then we would have to add the library to the repository as well.
2. Fix the issue server-side. I’d be happy to look it at but I don’t have access to the source code.

Let me know what would be your preferred option.
Thanks :)

michiel

29-04-18 14:39

administrator   ~0060497

can you test with PHP5.4? I would be surprised if it's server side, when the code works for existing systems.
The server runs php5.4

I can dig out the server side code, but we will have to be very careful changing that.

samtuke

30-04-18 09:30

manager   ~0060499

@xheni Excellent investigation work, thanks.

@michiel how about moving the Soap API code from Sourceforge to Github to make it easier to patch?

xheni

30-04-18 09:42

developer   ~0060500

I also took a look at the details that client emailed and my guess was that they were not using the Soap client provided by phpList.
So I asked Suela to confirm that and turns out they are using https://paw.cloud to send the requests.

michiel

03-05-18 22:52

administrator   ~0060517

@samtuke Yes, definitely move the code from SF to Github. Where is it? I think the server code is on Gitlab though.

I think SF used to have the client code, but didn't you move that to Github already?

xheni

24-05-18 11:19

developer   ~0060635

Closing since we found a workaround for the client.

Issue History

Date Modified Username Field Change
20-04-18 09:43 suela New Issue
20-04-18 09:44 suela Status new => assigned
21-04-18 20:47 michiel Note Added: 0060454
21-04-18 20:47 michiel Summary The API seems to have stopped working. => The API does no longer work with newer versions of PHP (eg 7)
21-04-18 20:54 suela Note Added: 0060455
22-04-18 09:52 michiel Note Added: 0060456
22-04-18 15:57 xheni Note Added: 0060457
22-04-18 20:36 michiel Note Added: 0060460
27-04-18 08:58 suela Note Added: 0060481
27-04-18 11:40 suela Note Added: 0060482
27-04-18 12:04 samtuke Note Added: 0060484
27-04-18 22:16 xheni Note Added: 0060488
27-04-18 22:30 xheni Note Edited: 0060488 View Revisions
27-04-18 22:31 michiel Note Added: 0060489
29-04-18 10:24 suela Note Added: 0060494
29-04-18 10:25 suela Priority high => urgent
29-04-18 10:40 michiel Note Added: 0060495
29-04-18 14:03 xheni Note Added: 0060496
29-04-18 14:39 michiel Note Added: 0060497
30-04-18 09:30 samtuke Note Added: 0060499
30-04-18 09:42 xheni Note Added: 0060500
03-05-18 22:52 michiel Note Added: 0060517
24-05-18 11:19 xheni Status assigned => resolved
24-05-18 11:19 xheni Resolution open => fixed
24-05-18 11:19 xheni Note Added: 0060635
03-11-18 08:31 samtuke Project @174@ => phpList 3 plugins