No, it's not failing to find pear, it's failing to fine FileMaker.php. The bit about pear is telling you that the include path - the place where it's looking for FileMaker.php is in the directory c:\php\pear.
This makes me think that the server isn't using the FileMaker bundled version of PHP, but is in fact using a version which was (probably) already on the server before FM was installed. Usually on a Win server deployment the include path for the FileMaker installed version of PHP is something like (copied from a Win 2008 R2 server, with FM12 single machine install)
;C:\Program Files\FileMaker\FileMaker Server\Web Publishing\publishing-engine\php\PEAR;C:\Program Files\FileMaker\FileMaker Server\Web Publishing\publishing-engine\php\FileMaker;C:\Program Files\FileMaker\FileMaker Server\Web Publishing\publishing-engine\php
To confirm that, create a simple file in your web root folder i.php and place in it
<?php phpinfo(); ?>
Open that in a browser. This will show you the php.ini which has been loaded, for a FileMaker php install it will be something like
C:\Program Files\FileMaker\FileMaker Server\Web Publishing\publishing-engine\php\php.ini
If PHP is using an alternative php.ini, then you will now know which ini is being loaded. If there is no reason not to change things (e.g. code already on the server which requires specific modules) then I would suggest as a first port of call re-doing the FM server deployment and ensuring that the 'Use FileMaker version of PHP' option is checked.
If that doesn't resolve things, or you don't want to run the risk of upsetting other things on the server, then look in
C:\Program Files\FileMaker\FileMaker Server\Web Publishing
where you will be able to find
and then extract the content of that zip file into one of the include paths shown by i.php above.
This will then allow your code to find FileMaker.php when it goes to run by placing it on the global include path (or alternatively, as I tend to do, bundle the API code with your source code and refer to it via a resolvable relative path to the file(s) it's being included by).
Hope this makes sense and helps resolve things.
Thanks for the response.
I've done a lot of investigation since posting. I was aware of all of the above from the Mac perspective and had installed the filemaker standalone in the root of the web server with still no luck. The phpinfo() mentioned the path to the FMS version of PHP... but unlike when I do it on a Mac it mentioned about 3.
I then read :
... which pointed to 2 things:
1. enabling anonymous authentication BEFORE deploying the web publishing...
... so after this was fixed I attempted to re-deploy... and it was still not working
2. point 6.8 where the SSL was active... but not working properly.
I suspect #2 is the culprit and have asked the IT guy to read the rest of the help page to see if he can spot something else.
The IT guy had apparently decided to try using some php deployment tool which may have complicated things.
I've done windows installs before v 12 and have always managed to make it work despite the gaps in my knowledge. There is an extra layer of variables though this time.... very frustrating.
I will post again when I know more...
... almost there...
The FileMaker test page is working fine now.
The problem that remains is still a permission one. Permission is denied to write a session (ie for cookies) to the Windows/TEMP folder.
Sounds like good progress
That PHP can't write to the windows temp folder is a little weird…! but just add the correct user and your problems should be solved…
I sighed with relief when the fmi-test.php page worked then went to my pages... then THAT!
The usual story has always been that something would go wrong on windows. Now Mac OSX basic installs also throw up little things that usen't to be... like having to change the httpd.config file to turn PHP on for Apache since 10.6 and the various php.ini configs for uploads etc.
I suppose my biggest frustration of the day was having to use Notepad to edit configs... so no linebreaks...
Notepad++ it's the way of the (Windows) future
Well... that was a nightmare.
Basically it is all working other than a troubleshoot on upload file paths.
So many different ways that PHP can be configured and unconfigured in iiS. The tech guy had it going around in circles. That and every firewall and security measure you can imagine. It has all been undone now and woking well.
Thanks Steve for the input. Unfortunately I can't give you points as I forgot to make this a Question... I'll try to remember next time and give you points for saying hello ;-)