rest interface problem, works in 7.6.10 with PHP 5.6.30 but not with PHP 7.1.2

[jobst]

When requesting or setting data through the rest interface it works with SuiteCRM 7.6.10 and PHP 5.6.30, but not with PHP 7.2.1 (even tried higher SuiteCRM version).

ADDED FOR CLARITY: other data is accepted happily, for example this is HTTP CODE 200: http://SERVERNAME/SuiteCRM/service/v4/rest.php?method=search_by_module&input_type=JSON&response_type=JSON&rest_data=%7B%22session%22%3A%227hfeg6e1nm2gbg7kjtg8p6mp00%22%2C%22search_string%22%3A%22jrh%40barrett.com.au%22%2C%22modules%22%3A%5B%22Contacts%22%5D%2C%22offset%22%3A0%2C%22max_results%22%3A10%2C%22assigned_user_id%22%3A%22%22%2C%22select_fields%22%3A%5B%22id%22%2C%22first_name%22%2C%22last_name%22%2C%22account_name%22%2C%22name%22%2C%22case_number%22%2C%22account_id%22%2C%22converted%22%5D%2C%22unified_search_only%22%3Afalse%2C%22favorites%22%3Afalse%7D

Issue

Using CURL to send this data:

http://SERVERNAME/SuiteCRM/service/v4/rest.php?method=get_entry_list&input_type=JSON&response_type=JSON&rest_data=%7B%22session%22%3A%22dp9g09geq76ocn8noepqm6h2i0%22%2C%22module_name%22%3A%22Emails%22%2C%22query%22%3A%22(message_id+%3D+%5C%22%3C42968260-49f8-8fc5-5efd-21b2d0fa9788%40barrett.com.au%3E%5C%22)%22%2C%22order_by%22%3A%22date_modified+DESC%22%2C%22offset%22%3A0%2C%22select_fields%22%3A%5B%22id%22%5D%2C%22link_name_to_fields_array%22%3A%5B%5D%2C%22max_results%22%3A1%2C%22deleted%22%3A0%2C%22favorites%22%3Afalse%7D

I am receiving a HTTP ERROR CODE of 500, but there are not many details why this is the case.

I really tried to find the problem with loads of debugging messages, but it does not give me any clue, even searching the server logs, nor looking at the traffic that is between the client and the server.

There is also not much too see in the logs about some php error or anything else, it simply fails.

The ONLY indication MIGHT BE this, it is happening at the same time when I do the request.

[11-Mar-2017 16:15:05 Australia/Melbourne] PHP Warning: Declaration of SugarWebServiceUtilv4::get_data_list($seed, $order_by = '', $where = '', $row_offset = 0, $limit = -1, $max = -1, $show_deleted = 0, $favorites = false) should be compatible with SugarW ebServiceUtilv3_1::get_data_list($seed, $order_by = '', $where = '', $row_offset = 0, $limit = -1, $max = -1, $show_deleted = 0, $favorites = false, $singleSelect = false) in /PATH/SuiteCRM/service/v4/SugarWebServiceUt ilv4.php on line 555 [11-Mar-2017 16:15:05 Australia/Melbourne] PHP Warning: Declaration of SugarWebServiceImplv4::get_entries($session, $module_name, $ids, $select_fields, $link_name_to_fields_array) should be compatible with SugarWebServiceImplv3_1::get_entries($session, $module_name, $ids, $select_fields, $link_name_to_fields_array, $track_view = false) in /PATH/SuiteCRM/service/v4/SugarWebServiceImplv4.php on line 49 [11-Mar-2017 16:15:06 Australia/Melbourne] PHP Warning: Declaration of SugarDateTime::setTime($hour, $minute, $sec = 0) should be compatible with DateTime::setTime($hour, $minute, $second = NULL, $microseconds = NULL) in /PATH/SuiteCRM/include/SugarDateTime.php on line 692

Expected Behavior

receive a client status (http code) of 200

Actual Behavior

receive a client status (http code) of 500 and no error message

Possible Fix

If I only knew ;-), I would have done it

Steps to Reproduce

1. use attached text file
2. change things in the file to match your sever
3. execute it
4. error 500
5. You need to have a version PHP higher than 7.
6. Sugar version 7,6,10

Context

I went back to 7.6.10 and PHP 5.6.30 for the time being - this way it works very happily.

Your Environment

• SuiteCRM Version used: 7.6.10, it fails definitely on 7.8.2
• Browser name and version (e.g. Chrome Version 51.0.2704.63 (64-bit)): N/A
• Environment name and version (e.g. MySQL, PHP 7): it fails with 7.2.1 but NOT with 5.6.30
• Operating System and version (e.g Ubuntu 16.04): CentOS 6.10

restproblem.php.txt

[urdhvatech]

That's correct. We are facing the same issue. Doesn't work on PHP 7.*

[chris001]

Have you looked to see if Travis-CI detects any issues with the SuiteCRM 7.8.2 code run tested under PHP 7.x ?

[jobst]

@chris001 no. I think this problem is related to PHP changing the way errors are handled. One of the problems I had yesterday to figure out what the error actually was.

I am still clueless ... I receive a 500 error but no reason and I have no idea where it is generated. I had not changed anything on my site other than upgrading PHP.

I turned all logs to full, even observed the traffic, wrote a PHP file that just sends the problem data via curl to the rest interface hoping I would see more ... I just do not know at what POINT it crashes and what piece of code is involved. On top of this OTHER data is handled quite happily.

My problem, too, my knowledge of the rest interface is a little limited.

... but I also think the latest PHP changes from 5.6.30 to PHP 7.1X are a major hassle in this especially the error reporting. I have some complicated projects that use api's/ajax/interface that used to throw errors happily when stuffing up code - last week I had an issue where I forgot a comma and added about 30 lines of code in different files only to end up with a white page and no error .... It was very hard to find.

[chris001]

Try setting in php.ini:

display_errors = On
display_startup_errors = On
log_errors = On
error_log = /home/path/to/your/file/php_error.log
error_reporting = E_ALL

[chris001]

http://php.net/manual/en/migration70.incompatible.php http://php.net/manual/en/language.errors.php7.php PHP 7 has some great improvements over PHP 5, much more uniform use of Exceptions for error handling which clears up most of the odd corner cases and reduces the general level of unreliableness common to old/legacy php apps due to having had to manually account for so many possible causes of errors, at every step of the way in an app.

[jobst]

@chris001 I know how to set error messages - there are just no errors returned from the rest interface. I also know that PHP 7 is an improvement - all of that does not help me in the moment. I highly recommend to send the data that I provided above, you will see - one works the other one doesn't and there is bugger all messages to debug it - and it used to work for plenty of years without issues.

[chris001]

I believe you @jobst SuiteCRM REST API (actually it's Sugar 6.5 REST API) is behaving differently under error conditions on PHP 5.x and PHP 7. The trick to debugging this issue in the REST API, since it's a remote call, is:

1. to get the server side SuiteCRM REST API code to log its exceptions to the PHP log, instead of the SuiteCRM code just muting the exceptions and discarding them to /dev/null, and,
2. there's something more advanced you can do, with PHP developer tools. Do you have the access to change some settings in your server's PHP configuration?

[jobst]

I am (g)root! ;-)

[chris001]

Haha. Can you say anything besides I am groot? Just kidding. You can activate the Xdebug PHP extension on the server, restart/reload the php engine, and remotely step thru the SugarCRM 6.5 REST API code from your PHP development app - phpstorm EAP version is great for this - to find the place where the exception is thrown, caught, and incorrectly discarded.

[jobst]

Can't do that in the moment, this is a production machine, normal week has started.

[chris001]

OK. If you area able to, you could make a clone of the production system on a local virtual machine, and try debugging on the clone system.

[jobst]

@chris001 how can get the server side SuiteCRM REST API code to log its exceptions to the PHP log, instead of the SuiteCRM code just muting the exceptions and discarding them to /dev/null?

[chris001]

@jobst You should see more info in your log when you go into Admin, System Settings, Logger Settings, Log Level, and raise the log level up to Info or Debug, and Save.

[jobst]

I know, but it still does not display the php based crash ;-( On top of all that got another problem in the moment, too. I copied the SuiteCRM install to another system (httpd not used for company work) so I can get PHP>7.1 installed. But I cannot get ^&%^&%& Thunderbird accepting that new Sugar URL. F%^%!

[chris001]

Try this code to access the REST API v4.1 included in SuiteCRM, it should work fine: http://www.curiousmentality.co.uk/2012/12/manually-debugging-the-sugarcrm-rest-api-with-curl/

[jobst]

@chris001, see #3343 This is ONE FIX ONLY, but it is a requirement.

[chris001]

@jobst It's looking good. You should use this app to help automatically find the problem areas of the code that won't run in php 7.1. Run these commands, from the base folder of your crm instance:

composer require --dev squizlabs/php_codesniffer dealerdirect/phpcodesniffer-composer-installer frenck/php-compatibility
composer update 
./vendor/bin/phpcs --standard=PHPCompatibility --runtime-set testVersion 5.6-7.1 ./ --extensions=php

This is pretty cool. It shows a lot of source code files with errors where SuiteCRM will crash when running on the latest version of PHP 7.1. Easy to fix them all in one PR.

[jobst]

@chris001! Ha! It did not discover the errors I found! On a second note, why are so many different versions kept of the rest interface?

[chris001]

@jobst The different versions of the rest interface are kept for backwards compatibility to not break all the versions of the 3rd party business apps, website portal connectors, and mobile phone apps needing to share data with the CRM thru the soap or rest web service API, tons of these apps are running out in the field, written in 2006, 2008, 2009, 2011, they depend on a certain version of the interface. It's no problem to keep the old interface versions available, this is the facade design pattern, when you need to update the interface with breaking changes, you make a new major version, keep the old version don't burn it that would break existing apps and ruin many users productivity.

If you can, try .scrutinizer.yml settings on your fork at scrutinizer-ci.com this ought to discover more errors.

[jobst]

@chris001, the testing tools did not find these ... that's not to say I made an error using the tools ;-). Also, this fixes MY problem but I am not sure whether there are other issues with other functions.

[tdseward]

Yes it was working in 5.6 and now with PHP 7.1 upgrade required for 7.8 fix to workflows it now does not work.