PHP3 files not working...

[infinite]

Hey everyone! I have just successfully installed Plesk 6.5 on my Server and I was wondering, WHY THE HELL DOES PHP NOT WORK??? I think it has to do with the way it is installed in the httpd.conf file... But, I also tried installing it as a CGI executable, which isn't safe to begin with, but that when I tried accessing the page it gave me several errors about missing modules. It isn't that the PHP installation completely doesn't work because it does show a white page, but I can only see the white page... Can anyone help me?

 

[sieb@]

hmm.. This is odd considering the control panel is all php. The missing modules is probably because they are not activated in the php.ini, I would start looking there.

 

[infinite]

OK I changed the variables in php.ini.... Now, I'm back to where I was with just a white page... When I viewed the source of the page I was able to see the PHP code... Which means that it's not interpereting the code... Someone please help me... I'm soooo stuck right now!!

 

[siren@]

6.5 for windows doesn't use the httpd.conf because it isn't running in Apache. Check your IIS configuration, per site configuration (the virtual directories) under scripting configuration to make sure .php, .php3, and .phtml are mapped properly.

 

[sieb@]

yea, under the virtual site/virtual dir/configuration/ there should be mappings for .php and .php3. PHP isn't installed per say, it looks like there is a custom mapping for it. All the modules are in the admin folder with some apache files. Its kinda odd..

 

[infinite]

OK wait... I'm getting this now:

Security Alert! The PHP CGI cannot be accessed directly.
This PHP CGI binary was compiled with force-cgi-redirect enabled. This means that a page will only be served up if the REDIRECT_STATUS CGI variable is set, e.g. via an Apache Action directive.

For more information as to why this behaviour exists, see the manual page for CGI security.

For more information about changing this behaviour or re-enabling this webserver, consult the installation file that came with this distribution, or visit the manual page.

Now what the hell do I have to do?

 

[tdscom]

Locate the cgi.force_redirect entry in your PHP.ini file, and edit it as follow :

cgi.force_redirect = 0

 

[siren@]

Don't link to the admin folder. Link to \plesk\php\php.exe

The admin folder is for the interface which runs on Apache. None of the sites run on Apache!. The modules are for Apache!

 

[infinite]

Ok here is everything I did so far:

installed Plesk
installed Plesk patch
installed php
installed perl

Editted the php.ini:
cgi.force_redirect = 0
changed the modules directory

Now when I go to the webpage (htdocs) it shows this:

.LPh,%)3(GyctKmLhEd0Dl*ZK!%EUs?lYQ*_Ii Pz;MD\eXj~]'.Ux<./Qk E=[9qtxJs5O 9nXI4;E6TZ9,D(z|9u]zi}."{SFNCDaFh\> gd1UX0bj[60^P|,G_5-tiH3G#jto _e9i?fE)^[I>_Yqy?/sV[: s!#}#9<%XK2
M:]@X9.Ea?| 5<vjlD@)T5qV O@(tBC=(%S ]50j[YH`3};"? _0GY]z .C!O IV>1(`h+S1iH~=[9qtxJs5O=bc`YbP RHg:73xts'\k9~fT@c*NgIN)i4Bb1h8_7ix?Z{e!yYCsSR4OI7m2VHrFb|lT~GA+Vcw&JnSXZowNd|&^To z|jGk*3 ^ | ;0FOPneLyW6^\fb|lT:a7*(<Ja/ ~0gI#VKbFX^!ExJy3~{)<V]P(wQhp>mya'ps01>w,JO&H4kb|lT:a7*(<Ja/ ~0gI#VKbFX^!ExJy3~{)<V]P(wc_|;u9I0Tbg} /

When I go to the https://myurl:8443 it shows just a blank white page!

Now I have explained exactly what's going on! Someone please help me!!!

 

[siren@]

You should not have installed PHP and Perl, if you want the ISAPI filters, should have been installed prior to Plesk.

 

[sieb@]

Don't link to the admin folder. Link to \plesk\php\php.exe. The admin folder is for the interface which runs on Apache. None of the sites run on Apache!. The modules are for Apache!

Yup, I figured that our after I said that. I don't get why they left them in there though..

 

[siren@]

They are used by the Plesk Control Panel which runs under Apache.

 

[infinite]

So what should I do now??

 

[siren@]

I would recommend a system rebuild. Start from scratch with a fresh install of windows. If this is impossible you are probably going to need help. There is no way I could walk you through the steps to repair this. I know we could probably do it, but ..........

So, if you can I would just start over with a fresh install.

 

[sieb@]

I have been messing with this all day with some test sites..

The problems I am having with php stem from the fact that PSA uses its own application pool instead of the default IIS application pool. Some sites work using the PSASystemAppPool, and others only work using the DefaultAppPool depending on how you mess with things.

I did some digging and basically all I had to do was map the isapi filter in application configuration (like your supposed to do with php) while still using the PSASystemAppPool.

.php "c:\program files\Plesk\php\sapi\php4isapi.dll"
.php3 " "

You also need to register it under the ISAPI Filters.

The only problem I have is that it runs deathly slow compared to using the php.exe.

 

[siren@]

I disagree. If you had left it alone it would have worked. We have PHP working w/ Plesk on IIS with no problems. But then again, we didn't install PHP after Plesk, nor attempt to link the PHP mapping to the PHP executable compiled for apache & PSA.

 

[siren@]

Also, if you remove that and remap under script configuration .php and .php to \plesk\php\php.exe it should run properly. Although from what you've said it sounds as if you have other problems now.

 

[sieb@]

On our clean install of PSA6.5, no PHP worked. I noticed that there was no mapping for .php which I added using the php4isapi.dll in Plesk (or the php.exe) and it all worked fine. I did not have to install PHP itself.

In the process of doing all this I messed with the AppPool settings and found other inconsistancies but, in the end, all you should have to do is map it and it should work fine.

Then again DDreams, it sounds like you have gotten all sorts of fixins from Plesk so they may have writen in that fix in the hotfixes, I just used the install and sp1.

 

[siren@]

On only one of our servers. We have 4 that are fresh installs of SP1 and 2 that were 6.5 updated to SP1.

Also, we manage multiple servers and do installs and have not seen a failure to map PHP.