FX.PHP and FM10>FM16..oddities. Help?

[Richard J]

Hi all

Moving a couple of Custom sites done with FX.PHP to Windows 2016 Server and from FMS 10 to FMS16.

After moving the pages to FMS16, some of them work - and some do not.
Yes, I changed all server_data.PHP files to the new IP and all references to the old database .fp7 names.
Still, some of the "search_result" pages that are invoked after a PHP search give me a 500 Server error.
If I make the query on those sites via a direct XML call to /fmi/xml/fmresultset.xml, all is fine.

So: something in the PHP code - in PHP or  in FX.php? - has changed its functionality vs what Filemaker can handle. Edit: or is it Filemaker that has changed it behaviour?
I updated FX.PHP way back to make it work on FM 10.
I used to run PHP 5.2.6 on the old box, and the new one has the 5.6.24 (for now, it needs updating to a more secure version).

Any specific pointers and tips are welcome.

Cheers from Sweden /R

Edited June 1, 2018 by Richard J
addition

[ggt667]

If you'd like I can log in and take a look.

 

If you make the query to: /fmi/xml/FMPXMLRESULT.xml there should be no changes to the XML grammar between the different versions of FileMaker Server.

/fmi/xml/fmresultset.xml on the other hand can change from version to version in FileMaker IIRC

Edited June 1, 2018 by ggt667

[Richard J]

" fmi/xml/fmresultset.xml on the other hand can change from version to version in FileMaker IIRC "

Sounds scary 🙂 but typical.

 

[jbschwartz]

I did one of these last year and had similar issues. Migrating from FMS 10 to FMS 16  involves upgrading not only FMS, but PHP and Windows as well. Lots of little things to go wrong but no fundamental hurdles  

Heres what I remember:

- Adjust IIS security settings to be able to see the actual error vs the useless 500 page. Or perform the operation from the server directly with full PHP error reporting  

- Eliminate PHP short tags

- Look for date format handling conflicts.   The solution I worked on had an automated logging routine that attempted to write a date in the wrong format on all operations. Apparently, either FMS or IIS or PHP had been upgraded to properly handle date format conversions and a legacy custom written function was no longer required. 

If I think of anything else I’ll let you know. 

Hope that helps. 

[Richard J]

Well, after getting some help from gtt667 and doing a little thinking/tinkering on my own over the last 3-4 days, this is what I found:

Some component in my old chain

( was php 5.2 > FXphp 4.0 >Filemaker 10 server,

now php 5.6.24 > FXphp 4.0 > Filemaker 16 Server )

has changed its behaviour from being fairly tolerant to being really picky. So: I needed to nitpick my old code, step by step. Here´s the result.

a) PHP pages now MUST be UTF-8. Nothing else allowed (yes, my sloppy coding).
b) ALL search terms now MUST have an operator attached (.cn  .eq  .bw etc).
c) clear any variables before use (sloppy coding again).

This way, I have got all sites running on the old FX.php version/code, and with PHP 5.6.24.
Done right from the beginning, my old code would have worked out of the box...

Next steps:

Try out the latest FXphp 4.6 and break everything again. 🙂  That will probably stop the system from whining about preg_replace /e all the time (and slowing things down). 

Once that works, upgrade to PHP 5.6.36 (more secure) or even PHP 7 and break everything once again 🙂

@JB, your tip about the useless 500 Server error page was very useful. I found a bit of code to be inserted into the web.config file that exposes those errors in all their ugliness, see below 🙂

https://blogs.iis.net/rickbarber/working-past-500-internal-server-error

All in all - thanks for your help so far. Cheers /Richard