php-windows Digest 29 Dec 2002 14:52:04 -0000 Issue 1508
Topics (messages 17575 through 17580):
Re: monster form and compression?
17575 by: Miha Nedok
win32 php.ini default behavior better in php executable directory?
17576 by: Petar
17577 by: Christoph Grottolo
17578 by: Sven Schnitzke
problems getting PHP to run again...
17579 by: M. Hockings
PHP 4.3 unable to load php_domxml.dll in WinXP Apache 2.0.43
17580 by: Rui Costa
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
Right now i'm reading the ChangeLog for 4.3.0 and Zlib is now bult-in, so
no need to load it via extenstion directive in php.ini.
-Mike
On Sat, 28 Dec 2002, Miha Nedok wrote:
> Date: Sat, 28 Dec 2002 13:37:02 +0100 (CET)
> From: Miha Nedok <[EMAIL PROTECTED]>
> To: Jeff D. Hamann <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], <[EMAIL PROTECTED]>
> Subject: Re: [PHP-WIN] monster form and compression?
>
>
> Look at your php.ini and search for:
> zlib.output_compression
> and set it to On.
> And add extension=php_zlib.dll
>
>
> -Mike
>
>
> On Fri, 27 Dec 2002, Jeff D. Hamann wrote:
>
> > Date: Fri, 27 Dec 2002 12:50:30 -0800
> > From: Jeff D. Hamann <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> > Subject: [PHP-WIN] monster form and compression?
> >
> > I have a monster form (really a funky grid - hey the client is always right)
> > that does not display entirely each time the form is displayed. Some times,
> > quite repeatably, the bottom half of the form's select boxes will be blank
> > (not good). Is there a way to compress the web page before it gets sent, or
> > any method to ensure the page will display correctly?
> >
> > Jeff.
> >
> > --
> > Jeff D. Hamann
> > Hamann, Donald & Associates, Inc.
> > PO Box 1421
> > Corvallis, Oregon USA 97339-1421
> > Bus. 541-753-7333
> > Cell. 541-740-5988
> > [EMAIL PROTECTED]
> > www.hamanndonald.com
> >
> >
> >
> >
> > --
> > PHP Windows Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> --
> PHP Windows Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
--- Begin Message ---
Hi All,
Sorry about the cross post but I suppose it applies in both areas.
I raised a few questions about getting an alternate php.ini recognised
when multiple php installs are on a windows 2000 server with no real
solution so far. I noticed 4.3.0 claims to have support for the
"-c /path/to/php.ini" which should allow the cgi version to use an
alternate php.ini file but it does not work under IIS5 and neither
does 4.2.3
I propose that the initial location php.exe should look for a php.ini
file is in the directory from which it executes. This would overcome
any issues with individual web servers on a win32 platform and allow
multiple configs/multiple copies of php to be executed without
trickery like the "-c /path/to/php.ini" which doesn't work.
I could then run a d:\client1\phpbin and e:\client2\phpbin without
any additional support required by the webserver. The size of php
is tiny and would not be an impost to run multiple copies. This system
would allow multiple version to run if required by simply changing the
cirtual directory structure in IIS5.
To keep the present 'default' behavior just make sure you don't
keep a php.ini in the executable directory and it should then run off
and look in c:\winnt like it does at present.
Anyone see a downside to this proposition?
Regards
..Petar
--- End Message ---
--- Begin Message ---
Petar wrote:
> Hi All,
>
> Sorry about the cross post but I suppose it applies in both areas.
>
> I raised a few questions about getting an alternate php.ini recognised
> when multiple php installs are on a windows 2000 server with no real
> solution so far. I noticed 4.3.0 claims to have support for the
> "-c /path/to/php.ini" which should allow the cgi version to use an
> alternate php.ini file but it does not work under IIS5 and neither
> does 4.2.3
>
> I propose that the initial location php.exe should look for a php.ini
> file is in the directory from which it executes. This would overcome
> any issues with individual web servers on a win32 platform and allow
> multiple configs/multiple copies of php to be executed without
> trickery like the "-c /path/to/php.ini" which doesn't work.
>
> Anyone see a downside to this proposition?
You can already do what you suggest. php.ini is read from the php executable
directory first. Try it out.
Christoph
--- End Message ---
--- Begin Message ---
Hello Petar,
it already works this way. But beware of using different versions of PHP: you
have to keep apart the Dll's too, because the interface description of e.g.
php4ts.dll changes from time to time. So clean up %WINDIR%, %WINSYSDIR%
etc of any PHP stuff and put your basic dlls in the same folder as PHP.EXE. And
keep a perfect track of the correct "extension_dir" for every PHP version.
Otherwise very very strange things happen because Windows jumps into the
DLLs right through the wall. Its not like the new registered versioned COM stuff of M$.
--
Sven
> -----Ursprüngliche Nachricht-----
> Von: Petar [SMTP:[EMAIL PROTECTED]]
> Gesendet am: Samstag, 28. Dezember 2002 14:02
> An: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Betreff: [PHP-WIN] win32 php.ini default behavior better in php executable
>directory?
>
> Hi All,
>
> Sorry about the cross post but I suppose it applies in both areas.
>
> I raised a few questions about getting an alternate php.ini recognised
> when multiple php installs are on a windows 2000 server with no real
> solution so far. I noticed 4.3.0 claims to have support for the
> "-c /path/to/php.ini" which should allow the cgi version to use an
> alternate php.ini file but it does not work under IIS5 and neither
> does 4.2.3
>
> I propose that the initial location php.exe should look for a php.ini
> file is in the directory from which it executes. This would overcome
> any issues with individual web servers on a win32 platform and allow
> multiple configs/multiple copies of php to be executed without
> trickery like the "-c /path/to/php.ini" which doesn't work.
>
> I could then run a d:\client1\phpbin and e:\client2\phpbin without
> any additional support required by the webserver. The size of php
> is tiny and would not be an impost to run multiple copies. This system
> would allow multiple version to run if required by simply changing the
> cirtual directory structure in IIS5.
>
> To keep the present 'default' behavior just make sure you don't
> keep a php.ini in the executable directory and it should then run off
> and look in c:\winnt like it does at present.
>
> Anyone see a downside to this proposition?
>
> Regards
>
> ..Petar
>
>
> --
> PHP Windows Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
I just got a new machine at work (hurrah!) and I'm trying to get it
running like the old one it is replacing. Both machines are running
Win2K. My problem is that PHP does not seem to be working on the new
machine. That is, if I try to load a php page via the Apache server on
the machine it gives me a 404 error even though the page does exist and
it will deliver other file types just fine. This is the snippet of my
http.conf file which is identical to the old machine except for the
different php directory.
ScriptAlias /pphpx/ "C:\ApacheGroup\php\php-4.2.3-Win32"
AddType application/x-httpd-php .php3
AddType application/x-httpd-php .php4
AddType application/x-httpd-php .php
Action application/x-httpd-php "/pphpx/php.exe"
This is running (or at least trying to run) Apache 2.0.43, PHP 4.2.3,
and Tomcat 4.0.12 (I think)
Any thoughts as to what might be amiss ?
Kind regards,
Mike
--- End Message ---
--- Begin Message ---
hi,
Windows XP, Apache 2.0.43(Win32) with PHP 4.3 can't load DLL
'php_domxml.dll'.
it pops-up: Unknown(): unable to load dll'C:\php\extensions\php_domxml.dll'
if I use the old 'php_domxml.dll' from PHP 4.2.4, it works fine. I'm using
libxml2-2.4.30, expat 1.95.4.
by the way, 'libxml2.dll' is not packed in the PHP 4.3 Windows distribution,
although it mentions that it does in the PHP documentation.
thanks in advance
rui
--- End Message ---
