Hi,
This has been driving me nuts for quite a while now. I've googled, and
looked at Plesk, php and Apache2 support forums for this but have no
more clues.
I have a box running Red Hat FC2, Apache 2.0.51 and PHP 5.0.4. The
client manages their websites through Plesk, which uses this notati
Please add this to b.php, and tell me what it outputs:
Ian Bambury wrote:
5.0.4-Win32 with Xitami 2.4
I posted here because it seemed probable that I need to set a switch
somewhere, although I haven't touched anything vital AFAIK. Xitami is
passing the file to PHP all right, and PHP is pro
5.0.4-Win32 with Xitami 2.4
I posted here because it seemed probable that I need to set a switch
somewhere, although I haven't touched anything vital AFAIK. Xitami is
passing the file to PHP all right, and PHP is processing it to some extent.
The source code for the resultant b.php page is
What version of PHP are you using?
Ian Bambury wrote:
Thanks for that, unfortunately it hasn't fixed the problem, true
though it may be.
files now read:
name:
--
name:
Querystring = http://127.0.0.1/b.php?xname=fred
...but still no joy. The "Hello" turn
Thanks for that, unfortunately it hasn't fixed the problem, true though it
may be.
files now read:
name:
--
name:
Querystring = http://127.0.0.1/b.php?xname=fred
...but still no joy. The "Hello" turns up, though.
Thanks,
Ian
Your problem is that arrays (including $_GET and $_POST) are
case-sensitive. Thus, $_GET['name'] is not the same thing as
$_GET['Name']. The name of the form field is "Name", so you'd have to
use $_GET['Name'].
Ian Bambury wrote:
Hi Everyone,
I'm probably being a bit thick here, but I can't ge
What version of MySQL are you using, and how did you install it?
Raf Goetschalckx wrote:
Hello,
i'm having a problem on my debian box regarding and apache.
It's the same problem as described in
http://bugs.php.net/bug.php?id=11029
Since no solution is actually given to that bug and they direct
Hi Everyone,
I'm probably being a bit thick here, but I can't get hold of $_GET or $_POST
variables. I've set up 2 files as simply as I can, but no joy.
File a.php
--
name:
---
produces http://127.0.0.1/b.php?name=fred
file b.php
-
Name:
-
pri
anybody else getting these bullshit msgs with viruses attached?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 29, 2005 1:47 AM
To: php-install@lists.php.net
Subject: [PHP-INSTALL] Your Email Account is Suspended For Security
Reasons
The origi
For security reasons alone, PHP 5 is an order of magnitude better than PHP 4
for production use. Read the update notes (RTFM).
~mark
-Original Message-
From: Daniel Brandauer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 29, 2005 1:30 AM
To: php-install@lists.php.net
Subject: [PHP-INS
Hello,
i'm having a problem on my debian box regarding and apache.
It's the same problem as described in http://bugs.php.net/bug.php?id=11029
Since no solution is actually given to that bug and they directed to the
mailinglist for help thats what I do.
phpinfo() output can be found @ http://www
WARNING: This e-mail has been altered by MIMEDefang. Following this
paragraph are indications of the actual changes made. For more
information about your site's MIMEDefang policy, contact
190.sy Administrator <[EMAIL PROTECTED]>. For more information about
MIMEDefang, see:
http://w
Daniel Brandauer wrote:
Hi All,
I have been unable to find a direct answer to this question on the net
so I am asking here. I need a definitive answer for a client. Let me
know if this is the wrong place.
Is PHP 5 "officially" ready for production use, or should important
systems stick wit
13 matches
Mail list logo
