[RESOLVED] PHP problems with quotes

EagleLink

Hi everyone, I'm not sure if this is a good place to post this, but I am in need of some desperate help and cannot seem to find what I'm looking for with Google.

Basic Info:

O/S: CentOS Linux 6.2
Apache: httpd.x86_64 1:2.2.15-15.el6.vm.1
PHP: php.x86_64 5.3.3-3.el6_2.8

Ok, so I'm switching from a VPS that was running CentOS 5 x86 (not 64) to a new VPS running the above. I've reinstalled everything, synchronized the files between servers for the web sites I host, and I seem to have a major problem (major to me) with the php print statement. So I created a test file from some code I found on the web...

<html>
<title>PHP Check File</title>
<body>
<?php
print "<h1>Congratulations, your server can process PHP!</h1>";
print "<h3>Here you can view the PHP configuration on your server</h3>";
exit();
?>
<h1>Sorry, PHP is not enabled on this server.</h1><br /><br />
<h3>Check your host provider documentation or contact
your host provider to ask them how to enable PHP.</h3>
</body>
</html>

This is how it comes up in the browser

Congratulations, your server can process PHP!"; print "
Here you can view the PHP configuration on your server
"; exit(); ?>
Sorry, PHP is not enabled on this server.


Check your host provider documentation or contact your host provider to ask them how to enable PHP.

The fonts do show up (The H1 and H3), but otherwise it's a disaster.

I then tried at the command line, "php phpcheck.html" and got these results

<html>
<title>PHP Check File</title>
<body>
<h1>Congratulations, your server can process PHP!</h1><h3>Here you can view the PHP configuration on your server</h3>

So, it seems that PHP is processing it properly when issuing the command directly, but somehow when done through Apache it gets messed up and ignores the end quotes.

Any help with this would be greatly appreciated. I only have a few days to switch over to the new server and this seems to be the only thing holding me up so far.

Thanks,
Jeff

bradgrafelman

Try changing the file to have a .php extension rather than a .html extension.

EagleLink

bradgrafelman;11007777 wrote:
Try changing the file to have a .php extension rather than a .html extension.

Unfortunately, that would defeat the purpose, but I will try it to make sure.

Ok, just tried it, and it seemed to show up perfectly.

Congratulations, your server can process PHP!
Here you can view the PHP configuration on your server

NOTE: There was a line after the last print statement to actually show the configuration, but I took it out.

Is there something wrong with the way Apache sends the in-line PHP to the PHP program?

The major problem is not with this test file I set up, but rather with an already existing web site design that is mostly HTML with a little embedded PHP. The already existing web site is having the same exact problem with the quotes. Here's a sample of the code on the existing web site.

if (file_exists('left.html')) {
print ('
<INSERT HTML CODE HERE>
');
}
else
{
print '
<INSERT HTML CODE HERE>
';
}
?>

Basically, the PHP checks if the file exists. If it does, then it inserts some HTML code to set up two IFRAME tags with the left.html and a right.html as their sources. If it doesn't exist, then it just inserts the code for one IFRAME with the right.html.

However, because it isn't seeing the end quote, I keep getting this...

'); } else { print ' '; } ?>

as well as an IFRAME that has

Not Found

The requested URL /left.html was not found on this server.

because it's not really seeing the end of the if statement or the else statement.

However, it shows up perfectly fine on the old server.

It's really confusing me. Is there something different about the way Apache calls PHP as opposed to my command line test?

bradgrafelman

EagleLink;11007785 wrote:
Unfortunately, that would defeat the purpose, but I will try it to make sure.

Why would that defeat the purpose? If your purpose is to get Apache to invoke the PHP parser, then I would think that giving the file a ".php" file extension would be just the thing to do.

If the purpose is not to get the file's contents parsed by the PHP parser, then sure, give it some other extension.

EagleLink;11007785 wrote:
Is there something wrong with the way Apache sends the in-line PHP to the PHP program?

Nope, sounds like it's working perfectly; files ending with ".php" are routed through the PHP parser, while other files are not. After all, why should Apache bother to invoke the PHP parser for a file if it wasn't meant to be parsed as a PHP script?

EagleLink;11007785 wrote:
The major problem is not with this test file I set up, but rather with an already existing web site design that is mostly HTML with a little embedded PHP.

"embedded PHP" doesn't really make sense; either a file is a PHP script meant to be run through the PHP parser rather than output directly, or it isn't. It doesn't matter if 99% of the file is static HTML content with one tiny PHP statement; that file was still meant to be executed as a PHP script, thus I would expect it to have a ".php" file extension.

EagleLink;11007785 wrote:
The already existing web site is having the same exact problem with the quotes.

The problem has nothing to do with quotes and everything to do with the file extension. When the file has a ".html" extension, Apache assumes that the file is an HTML document (after all, why shouldn't it?). Since the PHP parser is only interested in PHP scripts and not boring HTML documents, Apache skips the PHP parser altogether and simply outputs the contents of the file directly to your browser (which, of course, gets these weird "<?php" tags and doesn't know what to do with them).

Long story short: give your PHP scripts a ".php" file extension, and leave the ".html" file extension for only those files which are actually HTML documents.

To explain why it worked before, note you can make Apache forget common sense and force it to route all ".html" files through the PHP parser as well, but at that point your file extension doesn't really mean much anymore so you might as well be using ".ILikeWatermelons" or some other meaningless extension.

laserlight

EagleLink wrote:
Unfortunately, that would defeat the purpose

I don't see how that would defeat the purpose, unless you configure your web server differently.

EagleLink wrote:
Is there something wrong with the way Apache sends the in-line PHP to the PHP program?

Again, is this file a ".html" file or ".php"? Unless your web server is configured to treat ".html" files as PHP scripts, you're doing it wrong. Apache is not sending anything to the PHP interpreter at all.

Here's a test: view the source code of the page. What do you see? My guess is that you will see your PHP script's code in all its glory, not the output of the PHP script.

EagleLink

bradgrafelman;11007787 wrote:
Why would that defeat the purpose? If your purpose is to get Apache to invoke the PHP parser, then I would think that giving the file a ".php" file extension would be just the thing to do.

Except the purpose is not to just have PHP, but to have HTML and PHP. As I said, this was just a test file. The real file that I am trying to get working properly is an HTML file with a little but of PHP included.

bradgrafelman;11007787 wrote:
If the purpose is not to get the file's contents parsed by the PHP parser, then sure, give it some other extension.

You know, you don't have to be so damn rude about it!

bradgrafelman;11007787 wrote:
Nope, sounds like it's working perfectly; files ending with ".php" are routed through the PHP parser, while other files are not. After all, why should Apache bother to invoke the PHP parser for a file if it wasn't meant to be parsed as a PHP script?

You must not really know what you're talking about. Yes, other files do get routed through the PHP parser, at least the parts that have the <?PHP> tags in them. That is the purpose of the <?PHP> tags....to embed PHP into an HTML file.

bradgrafelman;11007787 wrote:
"embedded PHP" doesn't really make sense; either a file is a PHP script meant to be run through the PHP parser rather than output directly, or it isn't. It doesn't matter if 99% of the file is static HTML content with one tiny PHP statement; that file was still meant to be executed as a PHP script, thus I would expect it to have a ".php" file extension.

Quite wrong, it is something that is done all the time to just add a little PHP function to an already existing HTML web site.

bradgrafelman;11007787 wrote:
The problem has nothing to do with quotes and everything to do with the file extension. When the file has a ".html" extension, Apache assumes that the file is an HTML document (after all, why shouldn't it?). Since the PHP parser is only interested in PHP scripts and not boring HTML documents, Apache skips the PHP parser altogether and simply outputs the contents of the file directly to your browser (which, of course, gets these weird "<?php" tags and doesn't know what to do with them).

You just said it yourself, PHP is only interested in the PHP scripts. So why would it bother with the HTML? The site was originally designed in HTML and PHP added in afterwards.

bradgrafelman;11007787 wrote:
Long story short: give your PHP scripts a ".php" file extension, and leave the ".html" file extension for only those files which are actually HTML documents.

If it were actually a PHP script, I would, but it's not. IT'S AN HTML FILE!

bradgrafelman;11007787 wrote:
To explain why it worked before, note you can make Apache forget common sense and force it to route all ".html" files through the PHP parser as well, but at that point your file extension doesn't really mean much anymore so you might as well be using ".ILikeWatermelons" or some other meaningless extension.

No, it worked before because it was done the proper way, as I have always done it, on multiple servers, many times, and so have other people.

AGAIN, I CANNOT STRESS ENOUGH, THIS IS AN HTML FILE WITH A LITTLE BIT OF PHP INCLUDED IN IT.

And in case you didn't notice, I DID NOT get any "<?php" tags in my browser.

PLEASE, READ AND UNDERSTAND EVERYTHING BEFORE YOU REPLY!

Can I now get someone who REALLY knows what they're talking about?

laserlight

EagleLink wrote:
You just said it yourself, PHP is only interested in the PHP scripts. So why would it bother with the HTML? The site was originally designed in HTML and PHP added in afterwards.

Once you add in some PHP code, you have a PHP script. Even if you are only using PHP as a template language, you have a PHP script.

EagleLink wrote:
No, it worked before because it was done the proper way, as I have always done it, on multiple servers, many times, and so have other people.

It worked before because your web server was configured to serve files with a ".html" extension as a PHP script.

EagleLink wrote:
And in case you didn't notice, I DID NOT get any "<?php" tags in my browser.

Did you view the source?

EagleLink wrote:
Can I now get someone who REALLY knows what they're talking about?

Both bradgrafelman and I know what we are talking about. Setting up and configuring a server from scratch with PHP support is really no big deal for me, and I doubt it is a big deal for him.

bradgrafelman

EagleLink;11007797 wrote:
Except the purpose is not to just have PHP, but to have HTML and PHP.

Right, but like I said, at that point, the file itself is no longer an HTML document - it's a PHP script. (No one said a PHP script has to have more PHP than HTML.)

EagleLink;11007797 wrote:
You know, you don't have to be so damn rude about it!

Wasn't aware I was being rude. Your PHP code wasn't getting parsed, thus I suggested you do something to make Apache realize it should get parsed - namely, give the file a proper file extension.

EagleLink;11007797 wrote:
You must not really know what you're talking about.

You know, I think you're right. My 17.7 thousand other posts and years of experience mislead me to believe otherwise. Apologies. :rolleyes:

EagleLink;11007797 wrote:
Yes, other files do get routed through the PHP parser, at least the parts that have the <?PHP> tags in them.

How do you know? You haven't said anything to suggest that is true. How did you configure Apache to invoke the PHP parser?

EagleLink;11007797 wrote:
That is the purpose of the <?PHP> tags....to embed PHP into an HTML file.

No it isn't; the purpose of the tags are to let the PHP interpreter know when it should enter PHP mode versus when it should pass data along untouched and unparsed. Using (or not using) the <?php .. ?> tags won't matter if the webserver doesn't know that it should be invoking the PHP interpreter in the first place, though.

EagleLink;11007797 wrote:
Quite wrong, it is something that is done all the time to just add a little PHP function to an already existing HTML web site.

So what's the opposite of "embedded PHP" ? Unembedded PHP? What on earth does that look like? (And when did you invent it?)

EagleLink;11007797 wrote:
You just said it yourself, PHP is only interested in the PHP scripts. So why would it bother with the HTML?

The HTML content or the HTML files? It will of course ignore anything (such as HTML markup) outside of <?php .. ?> tags - that's their purpose (as noted above).

EagleLink;11007797 wrote:
The site was originally designed in HTML and PHP added in afterwards.

... at which point you changed the purpose of the files. A file with "<?php" in it is not an HTML document - it's a PHP script (one that may or may not contain parts of an HTML document somewhere inside of it outside of the PHP code).

EagleLink;11007797 wrote:
If it were actually a PHP script, I would, but it's not. IT'S AN HTML FILE!

No, it's not. At least, it isn't if you have "<?php" anywhere in it.

EagleLink;11007797 wrote:
No, it worked before because it was done the proper way, as I have always done it, on multiple servers

I would disagree with the use of "proper" there, but I don't doubt it's worked for you in the past (mostly because you don't seem to be understanding the above points). And just because "other people" have done a thing doesn't make it in any way proper. (Other people used to swear the Earth was flat, y'know.)

EagleLink;11007797 wrote:
AGAIN, I CANNOT STRESS ENOUGH, THIS IS AN HTML FILE WITH A LITTLE BIT OF PHP INCLUDED IN IT.

...which means it actually isn't an HTML file at all.

EagleLink;11007797 wrote:
And in case you didn't notice, I DID NOT get any "<?php" tags in my browser.

Oh, but I'm betting you did. I'm betting you copied and pasted what your browser displayed to you after it rendered the data it got from Apache as if it were an HTML document. Did you try viewing the source code of the page (instructions vary according to which browser you're using) that your browser attempted to create (but failed because it got non-HTML markup such as "<?php")?

EagleLink;11007797 wrote:
PLEASE, READ AND UNDERSTAND EVERYTHING BEFORE YOU REPLY!

I did. Did you?

EagleLink

bradgrafelman;11007801 wrote:
Right, but like I said, at that point, the file itself is no longer an HTML document - it's a PHP script. (No one said a PHP script has to have more PHP than HTML.)

Except that when you have an ENTIRE sight designed with HTML, it it a lot easier to embed a little PHP into an HTML file then to go through the entire site changing everything.

bradgrafelman;11007801 wrote:
Wasn't aware I was being rude. Your PHP code wasn't getting parsed, thus I suggested you do something to make Apache realize it should get parsed - namely, give the file a proper file extension.

Well now you know.

bradgrafelman;11007801 wrote:
You know, I think you're right. My 17.7 thousand other posts and years of experience mislead me to believe otherwise. Apologies. :rolleyes:

Exactly the attitude of someone who THINKS they know what they're talking about.

bradgrafelman;11007801 wrote:
How do you know? You haven't said anything to suggest that is true. How did you configure Apache to invoke the PHP parser?

In fact I have, I have said that it worked on the other servers. And since you don't know how to do it, here's what you need to do.

Add the following to your httpd.conf

AddType application/x-httpd-php .htm .html

bradgrafelman;11007801 wrote:
No it isn't; the purpose of the tags are to let the PHP interpreter know when it should enter PHP mode versus when it should pass data along untouched and unparsed. Using (or not using) the <?php .. ?> tags won't matter if the webserver doesn't know that it should be invoking the PHP interpreter in the first place, though.

Ahhh, but it does. Or at least it's supposed to.

bradgrafelman;11007801 wrote:
So what's the opposite of "embedded PHP" ? Uembedded PHP? What on earth does that look like? (And when did you invent it?)

The opposite of "embedded PHP" would be that it's a PHP file automatically passed to PHP by the web server based on it's extension, where as "embedded PHP" is in a different file, such as HTML, so that you don't have to change everything else on your site.

bradgrafelman;11007801 wrote:
The HTML content or the HTML files? It will of course ignore anything (such as HTML markup) outside of <?php .. ?> tags - that's their purpose (as noted above).

Exactly, so if I ever wanted to add any other embedded stuff into it, it wouldn't be processed if it were a .PHP file.

bradgrafelman;11007801 wrote:
... at which point you changed the purpose of the files. A file with "<?php" in it is not an HTML document - it's a PHP script (one that may or may not contain parts of an HTML document somewhere inside of it otside of the PHP code).

Nope, wrong again. a PHP script is exactly that. I've never seen a PHP script (at least designed by a real PHP pro) that didn't start with <?PHP in the first place and ahve straight PHP to the end.

bradgrafelman;11007801 wrote:
No, it's not. At least, it isn't if you have "<?php" anywhere in it.

Again, many people would argue with that. It could very well have other things that are processed before it goes out to the client, such as SSI like "". Things like this are often messed up if the file is only processed by PHP because it has a .php extension.

bradgrafelman;11007801 wrote:
I would disagree with the use of "proper" there, but I don't doubt it's worked for you in the past (mostly because you don't seem to be understanding the above points). And just because "other people" have done a thing doesn't make it in any way proper. (Other people used to swear the Earth was flat, y'know.)

It is apparently you that are not understanding the point.

bradgrafelman;11007801 wrote:
...which means it actually isn't an HTML file at all.

Oh, but it is.

bradgrafelman;11007801 wrote:
Oh, but I'm betting you did. I'm betting you copied and pasted what your browser displayed to you after it rendered the data it got from Apache as if it were an HTML document. Did you try viewing the source code of the page (instructions vary according to which browser you're using) that your browser attempted to create (but failed because it got non-HTML markup such as "<?php")?

Nope, not at all. I've viewed the page source through Firefox as well as Internet Explorer and the code was not there.

bradgrafelman;11007801 wrote:
I did. Did you?

Absolutely, now you should do the same....for real.

But don't worry about it, I fixed the problem by removing PHP altogether and re-installing it. There must have been something corrupted when it was compiled in the first place. Now go find someone else to but that might believe everything you say.

laserlight

EagleLink wrote:
In fact I have, I have said that it worked on the other servers. And since you don't know how to do it, here's what you need to do.

Add the following to your httpd.conf

This is what we mean by configuring your web server to serve ".html" files as PHP scripts. I would be very surprised if bradgrafelman did not know how to do this.

I am going to put on my moderator cap now and inform you that you have crossed the line: stop being patronising in order to troll bradgrafelman. His answers to you were not rude at all, whereas your replies are rude.

EagleLink wrote:
The opposite of "embedded PHP" would be that it's a PHP file automatically passed to PHP by the web server based on it's extension, where as "embedded PHP" is in a different file, such as HTML, so that you don't have to change everything else on your site.

You are mistaken, because your showing of the Apache configuration clearly indicates that you expected your HTML files to be treated as PHP scripts.

EagleLink wrote:
Nope, wrong again. a PHP script is exactly that. I've never seen a PHP script (at least designed by a real PHP pro) that didn't start with <?PHP in the first place and ahve straight PHP to the end.

You just saw such a PHP script when you changed your test script from post #1 to have a ".php" extension and then ran your script and "it seemed to show up perfectly". The reason why you don't normally see this written by professionals in the field is that unless you are using PHP as a template language, this kind of combination of logic implemented by PHP with presentation done by HTML mixed together is poor practice.

EagleLink wrote:
But don't worry about it, I fixed the problem by removing PHP altogether and re-installing it. There must have been something corrupted when it was compiled in the first place.

If you did configure Apache correctly, then I suspect that you merely forgot to restart the web server. During the course of your re-installation of PHP, you would have restarted the web server, hence the configuration change to treat files with a ".html" extension as PHP scripts took effect.

bradgrafelman

EagleLink;11007803 wrote:
Except that when you have an ENTIRE sight designed with HTML, it it a lot easier to embed a little PHP into an HTML file then to go through the entire site changing everything.

Sounds like problem started in your designing phase then. Although, I fail to see why you would need to go "through the entire site changing everything" (after all, URLs aren't directly coupled to file paths).

EagleLink;11007803 wrote:
Well now you know.

I know you're a stubborn, misinformed web designer that should probably stick with cute WYSIWYG editors than venture into the world of actual programming, aye.

EagleLink;11007803 wrote:
In fact I have, I have said that it worked on the other servers.

Why would the fact that it works on other servers have any bearing on why it is or isn't working on the server at hand? You do realize not all web servers in the world share the same global configuration, right?

EagleLink;11007803 wrote:
And since you don't know how to do it, here's what you need to do.

Ah, but I do know all about that (I even talked about it in my very first reply). But as I also talked about, that seems more like a cheap workaround - the solution is to give your files more meaningful file extensions.

EagleLink;11007803 wrote:
Ahhh, but it does. Or at least it's supposed to.

It's supposed to according to you, apparently. Not according to the authors of PHP who created the tags in the first place.

EagleLink;11007803 wrote:
The opposite of "embedded PHP" would be that it's a PHP file automatically passed to PHP by the web server based on it's extension, where as "embedded PHP" is in a different file, such as HTML, so that you don't have to change everything else on your site.

So you're expecting Apache to sniff every single resource requested, look for any occurrence of "<?php", and then - whether you wanted it to or not - automatically invoke the PHP parser?

Thankfully, webservers don't actually work like that.

EagleLink;11007803 wrote:
Nope, wrong again. a PHP script is exactly that. I've never seen a PHP script (at least designed by a real PHP pro) that didn't start with <?PHP in the first place and ahve straight PHP to the end.

You haven't seen much PHP at all, then, I take it?

EagleLink;11007803 wrote:
Again, many people would argue with that. It could very well have other things that are processed before it goes out to the client, such as SSI like "".

... which again suggests that it shouldn't have a ".html" extension but instead ".shtml" (for example).

EagleLink;11007803 wrote:
Nope, not at all. I've viewed the page source through Firefox as well as Internet Explorer and the code was not there.

Then you should probably pull your head out of your ass and take a second look. You can even clearly see part of the PHP code from the mangled output you posted.

Even better, use a terminal client like PuTTY or a text-only browser like Lynx (e.g. any application that doesn't understand HTML markup) and request the page from your webserver. (Note your head will also need to be extricated from your ass to do this as well; you may return it if you feel the need to reply again.)

EagleLink;11007803 wrote:
Absolutely, now you should do the same....for real.

Heh.. trust me, I've read every bit of this thread. I'm sure the other regulars around here will find your replies rather amusing as well.

EagleLink;11007803 wrote:
Now go find someone else to but that might believe everything you say.

I think you just accidentally the whole sentence there. Regardless, don't fret - I'm not worried about educating you any more. It's far more fun to be a rude ass and dissect the boatloads of ignorance (or is it stupidity) in your replies. 🙂

@: Bugger off with your 'moderator cap' - it's more fun to feed the trolls around here anyway.

EagleLink

laserlight;11007805 wrote:
This is what we mean by configuring your web server to serve ".html" files as PHP scripts. I would be very surprised if bradgrafelman did not know how to do this.

I am going to put on my moderator cap now and inform you that you have crossed the line: stop being patronising in order to troll bradgrafelman. His answers to you were not rude at all, whereas your replies are rude.

You are mistaken, because your showing of the Apache configuration clearly indicates that you expected your HTML files to be treated as PHP scripts.

You just saw such a PHP script when you changed your test script from post #1 to have a ".php" extension and then ran your script and "it seemed to show up perfectly". The reason why you don't normally see this written by professionals in the field is that unless you are using PHP as a template language, this kind of combination of logic implemented by PHP with presentation done by HTML mixed together is poor practice.

If you did configure Apache correctly, then I suspect that you merely forgot to restart the web server. During the course of your re-installation of PHP, you would have restarted the web server, hence the configuration change to treat files with a ".html" extension as PHP scripts took effect.

I know perfectly well how to run "service httpd restart". That was NOT the problem. When i said "removed PHP altogether" I meant exactly that, configuration and all. I did everything exactly as I had the first time, except it works now. And YES, he was rude. And you don't have to worry about me crossing the line. I will NEVER use this site again and have already written a message to the site owner.

bradgrafelma;11007807 wrote:
Sounds like problem started in your designing phase then. Although, I fail to see why you would need to go "through the entire site changing everything" (after all, URLs aren't directly coupled to file paths).

I know you're a stubborn, misinformed web designer that should probably stick with cute WYSIWYG editors than venture into the world of actual programming, aye.

Why would the fact that it works on other servers have any bearing on why it is or isn't working on the server at hand? You do realize not all web servers in the world share the same global configuration, right?

Ah, but I do know all about that (I even talked about it in my very first reply). But as I also talked about, that seems more like a cheap workaround - the solution is to give your files more meaningful file extensions.

It's supposed to according to you, apparently. Not according to the authors of PHP who created the tags in the first place.

So you're expecting Apache to sniff every single resource requested, look for any occurrence of "<?php", and then - whether you wanted it to or not - automatically invoke the PHP parser?

Thankfully, webservers don't actually work like that.

You haven't seen much PHP at all, then, I take it?

... which again suggests that it shouldn't have a ".html" extension but instead ".shtml" (for example).

Then you should probably pull your head out of your ass and take a second look. You can even clearly see part of the PHP code from the mangled output you posted.

Even better, use a terminal client like PuTTY or a text-only browser like Lynx (e.g. any application that doesn't understand HTML markup) and request the page from your webserver. (Note your head will also need to be extricated from your ass to do this as well; you may return it if you feel the need to reply again.)

Heh.. trust me, I've read every bit of this thread. I'm sure the other regulars around here will find your replies rather amusing as well.

I think you just accidentally the whole sentence there. Regardless, don't fret - I'm not worried about educating you any more. It's far more fun to be a rude ass and dissect the boatloads of ignorance (or is it stupidity) in your replies. 🙂

@: Bugger off with your 'moderator cap' - it's more fun to feed the trolls around here anyway.

Just so you know, I write everything in notepad. So again, stop being rude and assuming things. The fact that it works on other server DOES mean it should work on this one, because it DOES have the exact same global configuration. When i talk about a server, I'm not talking about a web hosting account on a shared web hosting system. I'm talking about an actual server, something I have set up and configured everything on myself with root access. So yes, it is configured exactly the same as far at Apache and PHP were concerned.

You are clearly the one with your head in your ass, it's so far up there you can't even see.

bradgrafelman

EagleLink;11007809 wrote:
I will NEVER use this site again

Finally! Don't let the door hit you in the ass on your way out. 🙂

laserlight

bradgrafelman wrote:
@: Bugger off with your 'moderator cap' - it's more fun to feed the trolls around here anyway.

Bah, I was busy defending your Mr Nice Guy approach, and you had to go and blow it.

Anyway, since it seems that only insulting is left to do in this thread: thread closed (hmm... a little delayed, but lunch was calling out my name)