Re: [PHP-DEV] Moderate PHP-DEV
On Wed, 12 Mar 2003, Sascha Schumann wrote: Yes, because getting a cvs account is just *s* hard. The problem is that you easily lose valuable postings when you force people to go through some restrictive system. I'm especially worried about inter-group communication. E.g. where php-dev is involved in a discussion with another group of people. If some developer list tries to protect itself from my input, I usually don't bother to jump through hoops. This happened just recently with group@ and the ASF board where some messages got stuck in a filter. Currently, unless someone points me elsewhere I only read messages from PHP core devs. You must be kidding. There are 20-30 emails on php-dev on normal days. That hardly makes up 10% of my personal email traffic. The volume is quite negligible from my POV. Let's implement the renaming and Shane's two section thing first before we evaluate more draconic measures. I agree, it's worth looking into more subtle and less controversial changes. Change the name, clarify its use (ex. move dev list signup..), and see what happens. Regards, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Re: function.main
On Wed, 12 Feb 2003, Gabor Hojtsy wrote: what is function.main? it keeps popping up on my requires and links to = yoru site but nuthin' happens That is if I understand correctly a link in an error message. So either PHP needs to hide that link in error messages, or the function.main shortcut shuold point to somewhere on the homepage, explaining what is function.main This was fixed in CVS awhile ago (4.3.1) and now points to the proper docs. See: http://bugs.php.net/bug.php?id=21499 How was that fixed? Will there be any links with those errors for function.main but for a different page, or no links? I think it would be nice to make http://php.net/function.main show something (preferably the same thing that this fixed error message points to), if applicable... It was fixed in that it will link to documention for include() or require() (depending on the error) instead of main(). So, it links to different yet more appropriate pages now. Not sure if/what other errors cause a link to here but I agree we may as well create a dummy page for main() with some hopefully helpful information. I just comitted main.xml in /info/ so have a look, comments welcome. Regards, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Re: function.main
On Wed, 12 Feb 2003, Gabor Hojtsy wrote: what is function.main? it keeps popping up on my requires and links to = yoru site but nuthin' happens That is if I understand correctly a link in an error message. So either PHP needs to hide that link in error messages, or the function.main shortcut shuold point to somewhere on the homepage, explaining what is function.main This was fixed in CVS awhile ago (4.3.1) and now points to the proper docs. See: http://bugs.php.net/bug.php?id=21499 Regards, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Isis extension
I would like to know if can I have it on PECL. (There is a lot of people in latin-america who needs to use it, in europe too.) Have a look here: http://pear.php.net/manual/en/guide-developers.php It'll tell you how to get your extension into PECL. It will be nice to add one more supported database to the list :) Regards, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] variables_order annoyance
On Tue, 14 Jan 2003, Rasmus Lerdorf wrote: Check out this bug report: http://bugs.php.net/16155 Ah thanks, that's where I remember the discussion from. I do disagree with one part: (c) It shouldn't be possible to prevent $_GET, $_POST, $_COOKIE, and $_FILES from being populated. Why in the world not? I explicitly need to be able to prevent $_COOKIE from being populated and showing up in $_REQUEST here at Yahoo because we have access functions that we want to force people to go through to fetch cookie data. I think we should just have a completely clean separation of variable ordering priority and superglobal array population. Before register_globals it made sense to just have one setting for this as you couldn't have one without the other, but today it doesn't make sense anymore. How about an ini setting for all autoglobals with all being boolean except request_autoglobal which takes on 'gpc'. This will solve your problem but will introduce one possible problem (aside from even more directives to keep track of). It's nice to document: $_REQUEST will always contain a mix of... Instead of: $_REQUEST may contain a mix of ... depending on your request_autoglobal directive. Sure currently it depends on variables_order but few know the true power of this directive and even fewer are tempted to mess with it. Having the contents being consistent is nice but is it required? One last thing. Some people ask for the ability to hide certain ENV and SERVER variables. This is a related topic that might want to be addressed at this time. One thought for env: 0 = Variable won't exist. 1 = Entire variable will exist. RUNLEVEL,PATH = Partial variable exists except these. BUT, this would mean getenv() would need to be brought into the picture too so this topic will need a new related idea and may want to be ignored for now :) It would sorta be like disable_variables vs disable_functions. Regards, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] variables_order annoyance
On Mon, 13 Jan 2003, Rasmus Lerdorf wrote: Guys, I think this was brought up before, and I somehow had the impression that we fixed it, but we didn't. Currently if variables_order does not contain a certain type then that type will not be populated in the $_FOO superglobal. So, if you set variables_order = GP because you only want Get and Post data in your $_REQUEST array, perhaps, and you have register_globals off, then $_COOKIE, $_ENV, $_SERVER will not be populated. This is a pain in the ass! The two concepts should be separate. Check out this bug report: http://bugs.php.net/16155 Regards, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI [packaging issues]
This goes with the PHP source approach:
By default, configure/make/make install compiles the CGI interface,
and then you have to make install-cli to get the CLI.
We just replace the make install-cli by urpmi/apt-get php-cli.
Just FYI, 'make install-cli' is not the only way to
install the CLI there, 'make install' may put it
there too. For example:
'make install' copies CLI to {prefix}/bin/php
./configure --with-apxs
'make install' copies CGI to {prefix}/bin/php
./configure --enable-cli
'make install' copies CGI to {prefix}/bin/php
./configure
This is because both --enable-cgi and --enable-cli
are defaults. If one specifies a module SAPI, such
as apxs, then CLI is copied as 'php' because
--disable-cgi is implicitly called. This manual
entry explains this further:
http://www.php.net/features.commandline
This email is for informational purposes only, I do
not agree or disagree with your proposal as I wouldn't
touch this with a large stick but just wanted to clear
up any possible misconceptions :)
Regards,
Philip
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZEND_NUM_ARGS()
On Sat, 4 Jan 2003, Sterling Hughes wrote:
Probably but it looks like that filetype(null); for example under windows
will return type directory...
So it looks an important bug too.
Its about as much of a bug as passing filetype(null) isn't a bug.
Okay, let's use filetype('somebogusname') as an example:
Linux:
- Returns boolean false
- E_WARNING about lstat failure...
Windows:
- Returns string 'dir'
- No E_WARNING
Is this how this is going to be forever? Is this behavior
suppose to be documented?
Regards,
Philip
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: hitcho
On 31 Dec 2002, Timothy Hitchens wrote: Docs: Setup a common thread of examples across all PHP documentation as 80% of all questions about PHP on lists could be answered with common examples across all functions in the documentation. 80% of all questions about PHP on the lists could be answered if people read the manual in the first place. Wait, make that 95% :) See also: google.com Regards, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: hitcho
Setup a common thread of examples across all PHP documentation as 80% of all questions about PHP on lists could be answered with common examples across all functions in the documentation. On Tue, 31 Dec 2002, Georg Richter wrote: On Tuesday 31 December 2002 22:39, Philip Olson wrote: 80% of all questions about PHP on the lists could be answered if people read the manual in the first place. Wait, make that 95% :) Philip, we need more examples (and also correct ones). Hitcho is absolutely right here. Were also discussed this during the last doc meeting in march 2002. Are more useful examples needed? Yes. Can the manual be improved? Yes. Will new better examples in the manual solve 80% of all problems? No. Do I want people like Hitcho to work on the manual? Hell yeah! Are my comments meant to be rude? No. Should people read the manual? Yes. Do people who post to the lists currently read the manual? Mostly No. Should they? Yes. Should they also do searches with google/archives before asking? Yes. Regards, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3.0 released
On Sat, 28 Dec 2002, Sander Steffann wrote: Hi All, There is a weird line in here too: * PHP Manual: Using PHP from the command line http://www.php.net/manual/en/features.commandline.php It's this one: By default when executing make, both the CGI and CLI are built and placed as sapi/cgi/php and sapi/cgi/php respectfully The second path is wrong, and respectfully should be respectively. These typos have been fixed in CVS, thank you for the report :) Regards, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] CLI and CGI defaults
Andrei already decided, that --enable-cli should not change it's
behavior for 4.3, allthough I think it's intuitive for --enable-cli to
disable CGI if --enable-cgi was not given, I don't have a problem with
it, as long as the NEWS entry is correct and Philip documents it
correctly :)
I also feel an explicit --enable-cli should do that but
regardless the current method has been documented. The
distinction can be seen in this unxmled excerpt:
If a module SAPI is chosen during configure, such as apxs,
or the --disable-cgi option is used, the CLI is copied to
{PREFIX}/bin/php during make install otherwise the CGI
is placed there.
Because CLI is a SAPI so I guess only module (web servers)
count. Anyway please have a look at:
http://cvs.php.net/diff.php/phpdoc/en/features/commandline.xml?r1=1.12r2=1.13
And make sure this is written correctly. If so, information
from it will also live in install.commandline. Btw, it sure
is weird writing examples when cgi and cli have the same
name and get installed at the location. I didn't change
those much. I also didn't add the history of what these
files were called in 4.2.x as I'm not fully sure how it all
worked back then *hint* *hint*.
Regards,
Philip Olson
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: ground rules
Please have a look at bug #21116 as it mentions php_printer.dll which is in php.ini but not in the distro. It does appear buildable as this dll can be found here: http://kromann.info/php4.php I'm not suggesting it be included as most likely it will be removed from php.ini like the others. This is in PECL now but that fact was never mentioned in NEWS. Also, what is the official way windows users are suppose to get PECL dlls? Build them themselves? Regards, Philip Olson On Sat, 21 Dec 2002, Edin Kadribasic wrote: I have changed bundled php.ini-dist and php.ini-recommended to reflect these changes. Thanks for compilinng the list. Edin - Original Message - From: Christoph Grottolo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, December 21, 2002 10:40 PM Subject: [PHP-DEV] Re: ground rules Hi Andrei Zmievski wrote: Everyone, I have just released 4.3.0RC4. Despite the quote in my signature, I am determined to keep this one the very last final RC of the interminable 4.3.0 development cycle. Towards that end, I will closely monitor the CVS commits and revert any that do not satisfactorily explain what critical or showstopper bug they are fixing. There are inconsistencies in php.ini on windows: The following extensions are listed in the [extensions] part of php.ini, but are not dlivered with the distribution: - ctype (now built in) - cybercash (?) - dotnet (build failure since months) - ingres (build failure since months) - tokenizer (now built in) The following extensions are part of the distribution but not listed in php.ini - gd2 - mime_magic - msql - xmlrpc - zip Maybe you can correct this before 4.3.0. At least the missing GD2 is bad. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC4: ground rules
Attatched is a patch that essentially goes back
to 4.2.3 behavior except the external auth will not
be available with PHP in safe mode. REMOTE_USER
exists regardless.
It seems some people also wanted an ini option, I don't
know how to do that! :)
References for this patch:
http://bugs.php.net/20441
http://cvs.php.net/diff.php/php4/sapi/apache/mod_php4.c?r1=1.132r2=1.133
On a related note, I'm curious why PHP_AUTH_TYPE does
not exist, only the variable AUTH_TYPE does (for me).
PHP_AUTH_TYPE has been documented forever, not sure if
it used to exist but various parts of PHP4 source make
it seem like it should.
Regards,
Philip Olson
p.s. Thanks to Wez and Steph for teaching me not to fear
the source.
On Fri, 20 Dec 2002, Andrei Zmievski wrote:
Everyone,
I have just released 4.3.0RC4. Despite the quote in my signature, I am
determined to keep this one the very last final RC of the interminable
4.3.0 development cycle. Towards that end, I will closely monitor the
CVS commits and revert any that do not satisfactorily explain what
critical or showstopper bug they are fixing. I am aware that
PHP_AUTH_USER issue raises certain concerns, but no one apparently could
make a patch. If, however, one appears very soon, I may consider it a
special one and apply it for 4.3.0.
-Andrei http://www.gravitonic.com/
The time from now until the completion
of the project tends to become constant. -- Douglas Hartree
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Index: mod_php4.c
===
RCS file: /repository/php4/sapi/apache/mod_php4.c,v
retrieving revision 1.148
diff -u -r1.148 mod_php4.c
--- mod_php4.c 1 Dec 2002 03:28:21 - 1.148
+++ mod_php4.c 21 Dec 2002 05:18:12 -
@@ -448,7 +448,7 @@
authorization = table_get(r-headers_in, Authorization);
}
if (authorization
-!auth_type(r)
+(!PG(safe_mode) || (PG(safe_mode) !auth_type(r)))
!strcasecmp(getword(r-pool, authorization, ' '), Basic)) {
tmp = uudecode(r-pool, authorization);
SG(request_info).auth_user = getword_nulls_nc(r-pool, tmp, ':');
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
So every tutorial and documentation on this would have to say this right? Ask your sysadmin what the CGI and CLI versions of your PHP are called, they could be anything as there is no standard. For the purpose of this (tutorial|documentation), we'll call CLI php-cli and CGI php-cgi. Same goes for all cgi scripts, they'll work some places but not others... And various RPM's would have different naming schemes depending on the maintainers preference. Regards, Philip On Wed, 18 Dec 2002, Andrei Zmievski wrote: On Wed, 18 Dec 2002, Andi Gutmans wrote: I doubt this will happen fast enough. We should just release the way we released 4.2.x, which as far as I know was php for CGI and php-cli for CLI or am I a bit behind things? :) Derick and I hashed it out on IRC and we have a proposal: We should keep 4.2.x behavior with some modifications. CLI and CGI should always be built unless disabled, and the executables should go into sapi/cli/php and sapi/cgi/php, respectively. In addition, 'install' target should be modified to detect whether the user is trying to install either one of these SAPIs, output a warning message regarding the potential naming problem, and stop. Let the user install CLI and CGI manually, basically. I really hope we can come to an agreement on this. -Andrei http://www.gravitonic.com/ * Quantum Mechanics: The Dreams of Which Stuff is Made. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
On Wed, 18 Dec 2002, Dan Kalowsky wrote: Cutting down on the list of receipients here... Philip please do not put this paragraph into the documentation. If there is any sure fire way to ensure that the latest version of PHP WON'T be installed on a system... it's to encourage end users to contact their system administrator. Just FYI, I never intended to put that anywhere, it was more of a point to show how bad this can be. A support nightmare is to encourage sysadmins to name the binaries whatever they feel like, with no set standard. This sounds like PHP 4.3.0 I have no solution except that whatever decision is made can be implemented in 4.3.0. PHP 4.3.0 can wait an additional month or three. I see no reason why 4.3.0 should be pushed out the door just so 4.3.1 can implement this MAJOR change. It sounds like the two will be combined again, if so, make it so in PHP 4.3.0 please. Same goes for if it's decided to keep the two separate. Let the new RC series begin! :) Regards, Philip Olson [snip] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Constants inside strings, sometimes
Hello,
I stumbled upon this feature today and am wondering
why it exists:
?php
error_reporting(E_ALL);
ini_set('display_errors', 1);
define('a', 'b');
$arr = array('a' = 'apple',
'b' = 'banana',
'c' = 'cranberry');
echo a $arr[a] \n; // apple
echo b {$arr[a]} \n; // banana (???)
echo c {$arr['a']} \n; // apple
echo d $arr[b] \n; // banana
echo e {$arr[b]} \n; // banana and E_NOTICE for
// undefined constant
echo f {a} \n; // {a}
echo $arr[a];// banana (expected)
echo $arr['a']; // apple
?
In otherwords, constants are looked for inside
strings under the following conditions:
a) It's an array key
b) {braces} are around the array
This seems like inconsistent behavior as that's
the only time they are looked for. This makes
sense outside of strings but inside of them only
if braces are used and with arrays? Please
explain. It seems to me that if someone wants to
use constants with array keys, don't put them in
strings.
Regards,
Philip Olson
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Location of getopt function
One way to find function information is through the php function reference: http://zend.com/phpfunc/function.getopt.php Provides information on when it's available, where it's defined, if it's documented, etc. Regards, Philip On Mon, 16 Dec 2002, l0t3k wrote: Markus, thanks for the link, but i was looking for the implementation of the PHP function as documented here http://www.php.net/manual/en/function.getopt.php i searched for PHP_FUNCTION(getopt) but got no hits... l0t3k Markus Fischer [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Sun, Dec 15, 2002 at 03:21:04PM -0500, l0t3k wrote : i've checked LXR, but i cant locate the implementation of getopt in CVS. im trying to provide a Windows implementation. HTH: http://lxr.php.net/find?string=getopt -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Can someone provide a history of this and the problems one will see when trying to run php.exe as a cgi (i.e. follows one of the many install texts out there). This is _sorta_ documented but not really, only the apache2 docs make any mention of it thus far. Regards, Philip On Sun, 8 Dec 2002, Alexander Wagner wrote: On Sunday 08 December 2002 01:02, John Coggeshall wrote: I think a big ole' message at the end of ./configure will drastically reduce the number of problems. With php.exe? *g* Also, perhaps a check could be put in the CLI version of PHP that would throw an error message if it is being used as a CGI... A _meaningful_ error-message in the right place would be the right thing (tm). Too many people don't read release-notes. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Wait, so there used to be a php-cli.exe ? Add that to the history request question :) And so a user tries to install via some install tutorial on foo.com, what problems/errors will they see when accessing via the browser? Philip On Sun, 8 Dec 2002, John Coggeshall wrote: I believe the issue here is that PHP won't display the proper HTTP headers in the CLI version: C:\ Php.exe test.php X-Powered-By: PHP/4.2.2 Content-type: text/html Testing 1 2 3 C:\ C:\ Php-cli.exe test.php Testing 1 2 3 C:\ -Original Message- From: Philip Olson [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 08, 2002 11:07 AM To: Alexander Wagner Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Christoph Grottolo'; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] php.exe - php-cgi.exe Can someone provide a history of this and the problems one will see when trying to run php.exe as a cgi (i.e. follows one of the many install texts out there). This is _sorta_ documented but not really, only the apache2 docs make any mention of it thus far. Regards, Philip On Sun, 8 Dec 2002, Alexander Wagner wrote: On Sunday 08 December 2002 01:02, John Coggeshall wrote: I think a big ole' message at the end of ./configure will drastically reduce the number of problems. With php.exe? *g* Also, perhaps a check could be put in the CLI version of PHP that would throw an error message if it is being used as a CGI... A _meaningful_ error-message in the right place would be the right thing (tm). Too many people don't read release-notes. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
On Sun, 8 Dec 2002, Marcus [iso-8859-1] Börger wrote: At 17:55 08.12.2002, Philip Olson wrote: Wait, so there used to be a php-cli.exe ? Add that to the history request question :) And so a user tries to install via some install tutorial on foo.com, what problems/errors will they see when accessing via the browser? There was no spoon :-) ok start again: Not sure what this means. There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. Please provide version numbers so it can be documented. Like, WHEN the changes happened. Thanks, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Modules/Extensions not in 4.3
The peardoc format will be phased out for peardoc2 which
uses several files, that is one per function, one for constants,
etc.
It makes sense to document PECL in the pear manual since PECL is
in pear.
Well, actually this what I wanted to hear :) I also think that moving
PECL module's manuals to PECL is the way to go. Those extensions are
mostly rarely used... We can make up a list in the manual about moved
extensions and some text about why this happened / happens...
IMO, a lot of extensions that are currently documented in the PHP
manual could be moved to PECL and PEAR doc. This would make the
PHP manual lighter to download, display, handle. The PHP manual
could keep documentation about the core extensions (still to be
defined).
This isn't really the question as we (the doc teams) don't make
these (php4/ext-pecl) decisions. I don't think anyone feels
the documentation of PECL modules belong in the php manual or
vice versa but the question is how and when to deal with the
moved extensions. When the php-dev team moves an extension we:
(a) Move the docs (phpdoc-peardoc)
Verify the docs are online in the pear manual before removed
from the php manual. (which means the peardoc vs peardoc2
craziness must also be dealt with)
(b) Make sure php.net/{extensionname} still does something
useful.
Whether filler pages or 404 handles this is in question.
And whether or not individual functions are kept track
of is another. Also, this may just refer to (c).
(c) Make a note in an up-and-coming phpdoc appendix page on
moved and removed extensions which may look like:
=
| Extension | Change | Reason | Moved in |
=
aspell removed pspell.. 4.3.0
cybercashremoved ...4.3.0
cybermut moved.. ...4.3.0
-
(d) ???
Ideally the php-dev team can provide a timeline for (some) future
moves and/or discuss each extension in detail and make a decision.
Maybe all moves have been completed?. For now, we rely on NEWS
entries.
Most of the above applies to removed extensions too except they
won't go into peardoc but rather remain in phpdoc for an
undisclosed (a long) amount of time. A few were removed in 4.3.0,
see NEWS and CVS entries for details. Removed/deprecated
extensions have been dealt with in a couple different ways:
(1) icap : php.net/icap simply redirects to php.net/mcal
icap docs are not generated.
(2) aspell : All deprecated functions have been listed for
quite some time. It also mentions use pspell
(3) Redirect to (c) above.
I prefer the second because of historical reasons and the
fact that users may still be using the old functions. For
how long will these docs remain? Should they ever go in the
appendix instead? Will this confuse users? These are good
questions :) Also, what is done may depend on the individual
extensions themselves although consistancy has its merits.
Regards,
Philip Olson
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Modules/Extensions not in 4.3
On Fri, 29 Nov 2002, Wez Furlong wrote:
IMO, the manual should include all of the maintstream PHP extensions.
The reasoning is that if someone downloads the PHP manual, they expect
to get the PHP manual and not have to hunt around for docs on extensions
X, Y, Z.
So mainstream is defined as which are bundled with the
PHP4 source, whether it's in PECL or not? Does anyone
know or have a list of what will go where and when? Is
the install, configure, and use process different for
PECL extensions? Why are any PECL extensions bundled in
PHP4 source? That seems to defeat the purpose.
Currently the php and pear docs are like separate entities,
perhaps we should tie them closer together. Like,
download-docs.php can include versions with the pear manual.
And php.net/{pearextension} can either redirect to or
load appropriate manual/info pages. Anyway, point is
they can be better and closer friends.
Remember that one of our goals is to move most of ext/* into PECL, but
still bundle these pickled extensions in our official release packages,
so the idea that PECL should be documented under PEAR is not such a good
one.
I'm not familiar with this topic. Currently PECL is documented
under PEAR, and since it's part of PEAR it makes sense. It's
hard enough to decide which extensions go into PECL let alone
which PECL are documented in what manual. I am curious what is
meant by most, that sounds a little scary and makes having
all extensions in one manual more attractive. Is there an
option to only download needed pecl at compile time, kinda
like how 'pear install foo' is done now? Or an option to
download each separate, or all of them at once? I don't see
why any PECL would be bundled. But anyway, back to the docs.
Some disadvantages of having the docs separate:
* phpdoc has a ton more translators.
* more people have phpdoc karma and feel comfortable
touching phpdoc source
* downloading two manuals and/or viewing two websites
* most living in pecl, yet many bundled in php4
With the main advantage being it would be in its proper home.
Again, IMO, the madness of having no less than 3 different docu systems
(phpdoc, peardoc and peardoc2) makes very little sense; why not just use
one system (tm) for docs? (let's save some developer brain power for
more useful things).
The peardoc/peardoc2 issue is temporary and confusing but will
be remedied at some point, not sure when. In fact, I personally
don't document pear because of it. The matter of a completely
separate PECL manual I also disagree with. Although who knows,
maybe if the build processes were more closely done together it
wouldn't be so bad.
So, what I'd like to see (and this seems reasonable, IMO) is:
o One doc download for the PHP core + bundled extensions (which may
reside in PECL).
o One doc download for the PEAR classes + non-bundled PECL extensions
o One doc download for extension developers (the streams and zend API
stuff needs a proper home).
o One doc system to rule them all (but keep it modular of course).
I agree with this except have reservations about some PECL
going in PEAR manual while others in the main manual. I
*strongly* agree with a uniform system but AFAICT it won't
exactly be the case with current plans (phpdocumentor).
Regarding the separate developers manual, the main reason it
hasn't already been done (aside from time constraints) is there
is question on whether it should be translated or not. I vote no
it shouldn't as that'd mean outdated developer docs as the zendapi
stuff seems to change a lot and translations are slow and
sometimes are just one-time operations. In fact, aren't the current
en zendapi docs already outdated? I don't know this topic. On a
related note, those PHP4/README.* docs would fit nicely in this
dev manual.
Regards,
Philip
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP Memory Error
I started a faq on this but anyway one can use K (kilobytes) or M (megabytes) for these type of directives. A plain integer == Bytes. Regards, Philip On Wed, 27 Nov 2002, John Coggeshall wrote: 67108860 bytes = 64 mb 64M will also work, I believe. John Jonathan Williams [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Could someone please help. Running Linux 7.3 RH with 512 MB Ram with Apache and PHP 4. I receive the following error and was wondering if anyone had any suggestions. The error: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 35 bytes) in /var/www/html/vc/test_fort/bootstrap.php on line 267. Is there a server setting eliminating the ability to allocate more memory. Any suggestions would be helpful. You can reply to [EMAIL PROTECTED] as well. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Stanislav Malyshev wrote:
PO Just to defend phpdoc a bit, this statistic is based on
PO a php manual generated on April 25, 2002, which is when
PO zend.com/manual/ was last updated. Also, missing functions
That's not exactly true. The phpfunc is updated much more frequently than
the manual (since it takes _a real lot_ of time to build the full
manual...) - usually, daily. Also, as far as I understand, the numbers are
taken from manual/PHP sources, not from generated manual.
So if something is not correct, it's because I messed something up or
something changed in the manual and phpfunc script no longer catch it -
but not because it's not updated. Can you point to some function that is
defined but listed as not defined? Did the manual structure change
substantially?
Yes, phpfunc updates daily and that is good (although it continues
to say last updated sept. 22). There are documented functions
listed as not documented but your last comment seems to decipher
why. Sorry to assume where those statistics are based although
this looks related as April 25 is close to April 17, which
is around when the big change happened.
The manual structure did substantially change at around April
17, 2002. Now the functions are in their own xml files, and
they all live in the reference/ directory. The old xml files
still exist but aren't updated anymore. So:
Old: en/functions/{extension}.xml
New: en/reference/{extension}/functions/{function}.xml
It sounds like this is where the problem lives. As a reference,
glob() was initially documented about six months ago and sha1()
about six days.
Regards,
Philip
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Concrete suggestion re: i18n messages
No, it does not to me. It means that translators need to have access to
the php4/ cvs module, which is something I'm very against.
Agreed.. The default messages stay in the source code and
are easily reachable for the developer.
(That is something I very much dislike about the current
phpdoc organization. Every time I want to change something
in the main English documentation, I need to hunt around for
remote, well-hidden xml files. The docs were more
up-to-date, if these files were easier to access.)
Please explain this a little more with a few specific
examples. And please write the phpdoc list with these
concerns. Maybe the structure can be further explained
in the doc HOWTO. Sometimes I find going to the URL of
the manual page helps figure out the location:
www.php.net/manual/en/language.variables.predefined.php
en/language/variables.xml
www.php.net/manual/en/tokens.php
en/appendices/tokens.xml (note it's in appendix in manual)
Finding functions and extension information is easy since the
big change about seven months ago, for example:
www.php.net/manual/en/function.{functionname}.xml
en/reference/{extensionname}/functions/{functionname}.xml
www.php.net/manual/en/ref.{extensionname}.php
en/reference/{extensionname}/reference.xml
Adding functions is simple, just go into the appropriate
extensions function directory and add the xml file. On
a related note, the change/split that happened awhile back:
Old: en/functions/{extension}.xml
New: en/reference/{extension}/functions/{function}.xml
/ini.xml
/reference.xml
/constants.xml
/functions.xml (autogenerated)
Don't edit functions.xml as it's an autogenerated list. Also
note that the Old files are still in CVS for historical and
archival purposes (the changelogs).
It does take a little getting used to but let's discuss it
a little so php-dev people will feel more comfortable. It
now seems intuitive to me although it's not perfect and
changes are still in progress. For example finding some
of the configuration directives can be difficult...
Regards,
Philip
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Redirect patch URL
Regarding this proposal, what happens if the url being redirected to has an error? Or if it's down for some reason, how can I still see my errors without bugging the sysadmin? Also, will CLI and CGI be affected too? Regards, Philip On Tue, 26 Nov 2002, John Coggeshall wrote: http://coogle.homeip.net:81/php/patches/error_redirect.txt John -Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 26, 2002 4:22 PM To: John Coggeshall Cc: 'PHP Developers Mailing List' Subject: Re: [PHP-DEV] Redirect patch URL On Tue, 26 Nov 2002, John Coggeshall wrote: http://coogle.homeip.net:81/php/patches/error_redirect.html Please check out this URL and let me know what you guys think of the second version of this patch. It basically is pretty solid at this point. Your diff is in the wrong order, the whitespace is totally screwed, and putting it in HTML makes it not readable at all. Can you please put up a patch in a plain text file and with the correct +/- things? Derick -- --- -- Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ --- -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] Redirect on Error
On the documentation side of things, each translation could include a page tentively called: English words you want to know It could be as simple as a three column table, such as: | English | German | Explanation | | Constant | Konstant | ... | | Undefined | Unbestimmt | E_NOTICE... | | Notice| Nachricht | E_NOTICE... | The explanation column could give the context of the word although maybe that's overkill. Also something to consider is the currently existing tokens page: http://www.php.net/manual/en/tokens.php Which lists T_SR, T_VARIABLE, etc. And it both shows some example syntax as well as a link to the appropriate [translated] manual page. Also, it seems one should understand the word 'array' before using functions named array_keys() or array(). And know the word NOTICE because of E_NOTICE... Regards, Philip p.s. please forgive my poor german. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
[snip] Really? Let's see on average each function generates @ least one warning message, so we have @least as many warnings as we have functions. Warning messages get constantly re-arranged, by having a separate database for them making changes to warning messages will become more complex then writing the actual code. So, people will in many cases cut corners and just RETURN_FALSE; without giving a detailed explanation. Most developers like to write code, not modify XML files and write essays for proof look @ http://www.zend.com/phpfunc/statistics.php, according to that page ~14% of all functions in PHP are not documented in the English language. Just to defend phpdoc a bit, this statistic is based on a php manual generated on April 25, 2002, which is when zend.com/manual/ was last updated. Also, missing functions are almost all from experimental and/or cvs only functions. Sure your point is still valid (php-dev would rather code than document) but the numbers are a little misleading... and that's why such a great phpdoc team exists :) Regards, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] php4/win32/install.txt
Hello all- Here's a small patch that mentions apache2 for windows users. Related bugs on this issue can be seen here: * http://bugs.php.net/bug.php?id=16744 * http://bugs.php.net/bug.php?id=18129 Bug #18129 virtually became a support thread for this topic. The following patch doesn't go into detail as I don't feel comfortable with the subject but it at least gives an idea on what to do. Anyone feel free to go into more detail or adjust the words below before commit :) --- win32/install.txt 26 Sep 2002 19:49:34 - 1.16 +++ win32/install.txt 19 Nov 2002 07:27:53 - @@ -48,6 +48,7 @@ Personal Web Server 3 and 4 or newer Internet Information Server 3 and 4 or newer Apache 1.3.x + Apache 2.0.x (experimental) OmniHTTPd 2.0b1 and up Oreilly Website Pro Xitami @@ -201,6 +202,21 @@ Installing PHP on Windows with Apache 1.3.x + + + ATTENTION: Apache 2 Users + +At this time, support for Apache2 is experimental. It's +highly recommended you use PHP with Apache 1.3.x and not +Apache2. Documentation for installing Apache2 on windows +can be seen here: + + http://www.php.net/manual/en/install.apache2.php + +With the basic difference being that when installing as a +module you'll use php4apache2.dll instead of php4apache.dll +Both files are included within this release. + + -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] karma++
Hello- I request karma for phpweb and php4/NEWS I will help close bugs related to these categories and help make improvements. Regards, Philip Olson user: philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $HTTP_RAW_POST_DATA
On Sun, 10 Nov 2002, Rasmus Lerdorf wrote: Hrm.. Ok, actually Hartmut changed this recently. See: http://cvs.php.net/diff.php/php4/main/php_content_types.c?login=2r1=1.21r2=1.22ty=u It works when you turn on always_populate_raw_post_data, right? When setting this on I assume it will always populate no matter what enctype is used. This isn't the case. In the little tests according to Brad, adding enctype=multipart/form-data to a post form will cause $HTTP_RAW_POST_DATA to not exist. This is even with aways_populate_raw_post_data = on. Until this is figured the documentation won't be updated and imho this directive is considered broke. I am unable to test cvs php module at this time nor am I a HTTP expert. I tested on 4.2.3 and the above behavior exists. Shouldn't always mean always? I'm unable to confidently decipher that diff. Regards, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $HTTP_RAW_POST_DATA
On Mon, 11 Nov 2002, Hartmut Holzgraefe wrote: Philip Olson wrote: When setting this on I assume it will always populate no matter what enctype is used. This isn't the case. In the little tests according to Brad, adding enctype=multipart/form-data to a post form will cause $HTTP_RAW_POST_DATA to not exist. This is even with aways_populate_raw_post_data = on. unless i did something stupid while testing this is also the case at least for 4.2.x (due to the way multipart forms are handled now to preserve memory on file uploads) ... I meant that in 4.2.3 it seems broke. Regardless of always_populate_raw_post_data setting, a POST form doesn't always populate $HTTP_RAW_POST_DATA like it should*. Related changelog entries: 4.2.0 - Fixed $HTTP_RAW_POST_DATA to be populated on a missing content-type when always_populate_raw_post_data is on. (Rasmus) 4.1.0 - Add config option (always_populate_raw_post_data) which when enabled will always populate $HTTP_RAW_POST_DATA regardless of the post mime type (Rasmus) So I'm not sure what to say. In 4.2.3 it's very possible to make $HTTP_RAW_POST_DATA not exist with this directive on (assuming POST data exists of course). Please advise if this behavior has or will change. Or explain why this is the case. Regards, Philip * Whether it should or not is in question. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Please help document headers_sent()
Hello-
headers_sent() has two new parameters as of PHP
4.3.0, these are passed in by reference. I see
no need to have to do:
$file = 'file.php';
$line = 4;
headers_sent($file, $line);
When one could simply do this:
headers_sent('file.php', 4);
But we can't, we get this error:
Fatal error: Only variables can be passed by reference
This doesn't seem important, forcing one to use
variables here seems odd, why? Yes is in the
proto but afaict it shouldn't be.
On a related note, I tried and failed to return
anything other then 1 while using these optional
parameters. I can't even tell if it's reading
the file. If someone could explain a little more
that would be very cool.
Regards,
Philip
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Please help document headers_sent()
On Wed, 6 Nov 2002, Wez Furlong wrote:
if (headers_sent($file, $line)) {
echo headers were sent by $file:$line;
}
[snip]
Hello Wez-
Ahh, that makes sense. I was a little off
base on that one! :) Will add an example now.
Regards,
Philip
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Please help document headers_sent()
I get a Segmentation fault with this script using
PHP CLI:
?php
headers_sent($file, $line);
?
philiprock:~$ php test.php
Segmentation fault
That's when no headers are sent before the call. But if
headers are sent beforehand, it works:
?php
print foo\n;
headers_sent($file, $line);
print $file : $line\n;
?
philiprock:~$ php test.php
foo
test.php : 2
With a fairly (a few weeks old) version of PHP CLI.
I am unable to do further tests at this time, in fact,
I am unable to build HEAD (it dies). Only CLI seems
to be affected, CGI works either way. Haven't
tested mod.
Regards,
Philip Olson
P.s. If no headers were sent, in CGI, $line gets
the value int 0. $file is an empty string.
On Wed, 6 Nov 2002, Philip Olson wrote:
On Wed, 6 Nov 2002, Wez Furlong wrote:
if (headers_sent($file, $line)) {
echo headers were sent by $file:$line;
}
[snip]
Hello Wez-
Ahh, that makes sense. I was a little off
base on that one! :) Will add an example now.
Regards,
Philip
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Please help document headers_sent()
On Wed, 6 Nov 2002, Ilia A. wrote: On November 6, 2002 07:10 pm, Philip Olson wrote: I get a Segmentation fault with this script using PHP CLI: ?php headers_sent($file, $line); ? philiprock:~$ php test.php Segmentation fault That's when no headers are sent before the call. But if headers are sent beforehand, it works: The crash has been fixed in the CVS. PHP CLI cannot send any headers because it is not ment for a webserver enviroment. While CGI, is mostly geared towards web servers and by default will try to send headers. Okay cool. I just built from CVS and can confirm it has been fixed :) This time I used --enable-debug too ;) I couldn't build from HEAD yesterday but it's okay today. Regards, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Re: Manual page suggestions (was: dba_open...)
Some function return NULL some return FALSE and some return either FALSE or NULL in case of an error. And some return -1, some iirc return 0. I believe this is because PHP is open source and developers provide return values based on their personal preferences. But I'm not a php-dev guy so am not fully sure on the specifics or the history associated with this phenomena. Each function is documented on what it returns. If it isn't, we add such documentation. Most functions return false on failure, not all. As long as 0 isn't expected, using != to compare is often what people do. People only use strict !== when they are 100% sure what it'll return. Some function use NULL to tell there was a parser error and FALSE for other errors. If so one cannot do something like: if (xxx() !== false) ... or if (!is_null(xxx())) ... instead you would have to use if (($res = xxx() !== false) !is_null($res)) ... If that's how the function behaves and is documented then so be it. I too find it a little confusing having functions return -1, 0, false or null but that's the way it is right now. Maybe this has been addressed? I posted the full thing already here. That also contains an analysis of some function documentations: http://marc.theaimsgroup.com/?l=php-devm=103376370906751w=2 That looks interesting and until such a rapid change happens, or a decision is made to use your doc method, we should continue to document functions in a consistent manner which means not including the failed return value in the proto. Regards, Philip Olson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #19848 [Ctl-Csd]: Wrong $_REQUEST values ($_FILESappearance is wacky)
is import_request_variables() affected? as for import_request_variables, I haven't modified that, simply because i'm not sure whether it should be modified... For now I'll leave it, if someone feels strongly about it either way, they can change it... I think they should be the same, if $_REQUEST does not have FILES, import_request_variables() shouldn't either. I lack the skills to implement this change but vote for it nonetheless ;) Mainly for consistency sake. Regards, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: #19848 [Ctl-Csd]: Wrong $_REQUEST values ($_FILES appearanceis wacky)
This change will make it into 4.3.0 right? Also, is import_request_variables() affected? Regards, Philip On 28 Oct 2002 [EMAIL PROTECTED] wrote: ID: 19848 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Closed Bug Type: HTTP related Operating System: *any PHP Version: 4.2.3,4,3.0-dev Assigned To: sterling New Comment: Fixed in CVS... $_FILES is no longer present in $_REQUEST... Previous Comments: [2002-10-24 18:42:14] [EMAIL PROTECTED] This test form strips 3 characters from the posted variable: FORM METHOD=POST ACTION= INPUT TYPE=text name=foo[a] VALUE=?=$foo['a']? INPUT TYPE=submit /FORM 2 dimensional array - this test form strips 8 characters from the posted variable: FORM METHOD=POST ACTION= INPUT TYPE=text name=foo[a][b] VALUE=?=$foo['a']['b']? INPUT TYPE=submit /FORM For every dimension added to the array, another 4 characters are scripted from the beginning of the posted variable. Works on PHP version less than 4.2.2 and earlier. [2002-10-20 22:17:12] [EMAIL PROTECTED] The 'voting' on php-dev was in favour for removing the $_FILES from $_REQUEST..as it doesn't make much sense to have them there. Just FYI. :) --Jani [2002-10-20 22:14:01] [EMAIL PROTECTED] Sterling Hughes is working on this issue, according to posts to php-dev. [2002-10-16 06:29:23] [EMAIL PROTECTED] Also got the same cases. form method=post action=test.php input type=checkbox name=server[] value=ASP input type=checkbox name=server[] value=C input type=checkbox name=server[] value=COLDFUSION input type=checkbox name=server[] value=JAVA input type=checkbox name=server[] value=PERL input type=checkbox name=server[] value=PHP /form print_r($_POST['server']); it comes out: --- Array ( [0] = ASP [1] = C# [2] = FUSION [3] = [4] = [5] = PHP ) Apache/1.3.26, Win98 [2002-10-15 15:21:27] [EMAIL PROTECTED] BTW, 17958 is no feedback. Well, that's pretty untrue ... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19848 -- Edit this bug report at http://bugs.php.net/?id=19848edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] --disable-cgi yet again
Shouldn't this be --disable-cli ? On Thu, 10 Oct 2002, Andrei Zmievski wrote: Can someone good with build system add --disable-cgi swtich, please? There is a patch in php-dev archives but it doesn't work against the current tree. I hate building cgi every time when I don't need it. -Andrei http://www.gravitonic.com/ Music expresses that which can not be said and on which it is impossible to be silent. -Victor Hugo -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] variables_order too powerful
Can someone look into this for 4.3.0? I think this would go nicely there. Regards, Philip On Tue, 16 Jul 2002, Philip Olson wrote: In this bug report: variables_order affects existence of php predefined variables * http://bugs.php.net/16155 The following tentative plan was made by Zeev: (a) Decouple variables_order from the $_* / $HTTP_*_VARS completely. (b) Make it possible to prevent $_ENV and $_SERVER from being populated. Something like: server_autoglobal = on env_autoglobal = off (c) It shouldn't be possible to prevent $_GET, $_POST, $_COOKIE, and $_FILES from being populated. This is a pretty interesting change, the php-dev crew may want to discuss it (and implement!). Regards, Philip Olson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] variables_order too powerful
In this bug report: variables_order affects existence of php predefined variables * http://bugs.php.net/16155 The following tentative plan was made by Zeev: (a) Decouple variables_order from the $_* / $HTTP_*_VARS completely. (b) Make it possible to prevent $_ENV and $_SERVER from being populated. Something like: server_autoglobal = on env_autoglobal = off (c) It shouldn't be possible to prevent $_GET, $_POST, $_COOKIE, and $_FILES from being populated. This is a pretty interesting change, the php-dev crew may want to discuss it (and implement!). Regards, Philip Olson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] passing variables need help
Hello John-
Please consider the following two locations:
http://www.php.net/support
http://www.php.net/variables.external
Regards,
Philip Olson
On Mon, 15 Jul 2002, John Flanagan wrote:
Lo,
I am a just starting with PHP and I am in the middle of building a site. What my
question is;
If I pass a variable to a page by www.mysite.com/index.php?page=support how do I
grab that variable and use it in the index.php.
I want to use the same index.php for the whole site and when I get the variable eg
support pass it in to a variable like pages/{$page}.php; to stop any directory
transversal attacks.
I would appreciate it if anyone could tell me how to get the variable from the URL.
Cheers,
John F
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug #18214 Updated: Request: Warning on assignment in IFexpression.
What are some other potential strict mode watches? Some people ask for an optional strict mode with various options, this could be a good start? Imagine a strict mode directive where when on, various options could be set at runtime, like assignment_inside_expression = true :) You can better do this discussion on php-dev, as not a lot people read the bug list. Here are a few related feature requests (with summary): #14285 - Wants strict mode, similar to: 'option explicit' in VBScript 'use strict' in Perl #14405 - Wants 'require strict argument' option, that affects all PHP functions. The name E_TYPE is suggested. #18214 - Wants warning option for assignment inside of an expression. Possible runtime option of assignment_inside_expression = true if in strict mode. How possible would it be to create an optional strict mode in PHP? This might help strict programmers feel more comfortable. error_reporting(E_ALL) is a start, using === vs == too. Some functions, like in_array(), have strict options now as well. Regards, Philip Olson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] cvs: phpdoc /en/reference/info/functions ini-set.xml
There are several inconsistencies similar to this one. main.c and similar just don't always look right. I never made an official bug report but check out this php-dev post: PHP_INI USER|PERDIR|SYSTEM|ALL http://marc.theaimsgroup.com/?l=php-devm=101198971703359 Currently this ini_set table is autogenerated from source, but the source isn't always real world and imho the ini_set() table should be as friendly as possible (no more support questions! :) Regards, Philip Olson. On Mon, 8 Jul 2002 [EMAIL PROTECTED] wrote: On Mon, 8 Jul 2002, Philip Olson wrote: philip Mon Jul 8 02:31:59 2002 EDT Modified files: /phpdoc/en/reference/info/functions ini-set.xml Log: register_globals can't really be set by USER with ini_set(). The documentation doesn't match the source now, which is: STD_PHP_INI_BOOLEAN(register_globals, 0,PHP_INI_ALL, So I guess we need to fix that too? Derick Index: phpdoc/en/reference/info/functions/ini-set.xml diff -u phpdoc/en/reference/info/functions/ini-set.xml:1.12 phpdoc/en/reference/info/functions/ini-set.xml:1.13 --- phpdoc/en/reference/info/functions/ini-set.xml:1.12 Tue Jun 18 08:06:10 2002 +++ phpdoc/en/reference/info/functions/ini-set.xml Mon Jul 8 02:31:58 2002 @@ -1,5 +1,5 @@ ?xml version=1.0 encoding=iso-8859-1? -!-- $Revision: 1.12 $ -- +!-- $Revision: 1.13 $ -- !-- splitted from ./en/functions/info.xml, last change in rev 1.23 -- refentry id=function.ini-set refnamediv @@ -975,7 +975,7 @@ row entryregister_globals/entry entry0/entry - entryPHP_INI_ALL/entry + entryPHP_INI_PERDIR|PHP_INI_SYSTEM/entry /row row entrysafe_mode/entry -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-DOC] cvs: phpdoc /en/reference/info/functionsini-set.xml
How about we add another column to the ini_set() docs that explain these issues. Like for register_globals say why it won't give you $id from GET, etc. But why you might want to set it at runtime. Basically, people assume can be set at runtime means the directive can be set at runtime, and most expect in the same way as setting in php.ini Regards, Philip Olson On Mon, 8 Jul 2002, Philip Olson wrote: There are several inconsistencies similar to this one. main.c and similar just don't always look right. I never made an official bug report but check out this php-dev post: PHP_INI USER|PERDIR|SYSTEM|ALL http://marc.theaimsgroup.com/?l=php-devm=101198971703359 Currently this ini_set table is autogenerated from source, but the source isn't always real world and imho the ini_set() table should be as friendly as possible (no more support questions! :) Regards, Philip Olson. On Mon, 8 Jul 2002 [EMAIL PROTECTED] wrote: On Mon, 8 Jul 2002, Philip Olson wrote: philipMon Jul 8 02:31:59 2002 EDT Modified files: /phpdoc/en/reference/info/functions ini-set.xml Log: register_globals can't really be set by USER with ini_set(). The documentation doesn't match the source now, which is: STD_PHP_INI_BOOLEAN(register_globals, 0,PHP_INI_ALL, So I guess we need to fix that too? Derick Index: phpdoc/en/reference/info/functions/ini-set.xml diff -u phpdoc/en/reference/info/functions/ini-set.xml:1.12 phpdoc/en/reference/info/functions/ini-set.xml:1.13 --- phpdoc/en/reference/info/functions/ini-set.xml:1.12 Tue Jun 18 08:06:10 2002 +++ phpdoc/en/reference/info/functions/ini-set.xmlMon Jul 8 02:31:58 2002 @@ -1,5 +1,5 @@ ?xml version=1.0 encoding=iso-8859-1? -!-- $Revision: 1.12 $ -- +!-- $Revision: 1.13 $ -- !-- splitted from ./en/functions/info.xml, last change in rev 1.23 -- refentry id=function.ini-set refnamediv @@ -975,7 +975,7 @@ row entryregister_globals/entry entry0/entry - entryPHP_INI_ALL/entry + entryPHP_INI_PERDIR|PHP_INI_SYSTEM/entry /row row entrysafe_mode/entry -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] $HTTP_*_VARS deprecation status request
Hello, Any idea if/when these variables won't be created by PHP? Regards, Philip Olson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] isset multiple arguments, when?
Hello, When did isset() allow for multiple arguments, was it 4.1.0? The closed feature request is here: http://bugs.php.net/12978 Neither NEWS or it mentions when this feature was implemented. Regards, Philip Olson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] socket_select() problems?
I only get [0], never [1]. Did about 40 tries. latest CVS ./configure --enable-sockets If you need more info, let me know. Regards, Philip Olson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php-announce
Hello, What's the exact protocol behind the announcements list? Usually announcements get posted but not always. Looking through news I see: 4.0.4 ? ? 4.0.6 memory limit patch a couple of php-gtk announcements 4.1.0 4.1.1 ? 4.2.0 As you can see, a few are missing. I'm sure 4.2.1 is soon on its way but how? who? when? :) Regards, Philip Olson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: list() limitations
The big question is: how would You (Philip,Yasuo) want list
to behave when it encounters a hash? Do you want to get the
keys ? Or the values? Or do you want to get the hashed
element on its own again as key = value ?
My opinion is:
$foo = array('a' = 'apple', 'b' = 'banana');
list($a,$b) = $foo;
print $a; // apple
print $b; // banana
This would be consistant with how list works with
numerical arrays. It gets the values, not the keys.
No, I don't think it's a good idea. That is why we have
array_(keys|values), it makes the code readable and it's easy
to understand.
This is understandable but list() works on values, it does
this for one type of array but not another.
For me, it would make most sense to have the following:
list($a, $b) = array('a' = 'apple', b = 'beer');
var_dump($a);
array(1) {
[a]=
string(5) apple
}
I don't think many would share _this_ behaviour.
All in all I think this would get too ambiguous if we would
change the behaviour. Unless someone comes with really
intuitive and useable I examples I don't think it should
change at all (the list construct).
Aside from saying it works on values for numerical arrays
I can't say much else. That is intuitive and consistant
to me, not ambiguous.
Regards,
Philip
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: list() limitations
Aside from saying it works on values for numerical arrays I can't say much else. That is intuitive and consistant to me, not ambiguous. It is :) Since we both already have different views. I suggest leaving it; it's not worth the trouble and using the array_(keys|values) is the most readable solution. You can't get off that easily :) Please tell me why it's ambiguous for list to get values from one array and not just the values from another. Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] list() limitations
Hello, the following behavior seems odd:
$foo = array('a' = 'apple', 'b' = 'banana');
// Notice - Undefined offset: 1
// Notice - Undefined offset: 0
list($a,$b) = $foo;
// This of course works as expected
while(list(,$ab) = each($foo)) {
print $ab;
}
I recently documented this numerical requirement (starting
at 0) as a note but find it odd. This is mentioned as a
bug in a few places but I can't find any closed reports.
It's a pretty good feature request, right?
Regards,
Philip
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: list() limitations
$foo = array('a' = 'apple', 'b' = 'banana');
// Notice - Undefined offset: 1
// Notice - Undefined offset: 0
list($a,$b) = $foo;
Isn't this line should be
list($a, $b) = array_keys($foo);
or
list($a, $b) = array_values($foo);
Sure that works.
I might miss you point, since it seems we are
going to make these feature requests bogus.
Why? list() working with associative arrays
seems bogus to you? Please be specific as to
why this is bad. Why is requiring keys indices
to begin at 0 good or necessary? I can't think
of a case where this will be bad for a php user.
Imho it's intuitive.
Sure it's not a major deal and more pressing
needs exist but hey, what can I say. :)
Regards,
Philip
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Streams are here!
Please please please test the following things in particular as I can't compile them or verify them here: I can't compile, because it complains about `ptrdiff_t' undeclared in main/network.c. I think stddef.h or similar is needed in this file. this also affects --enable-sockets, please fix soon i'm trying to test something ;)) philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new php.net shortcuts
$CUSTOM_SHORTCUTS = array ( 'ini' = 'configuration', 'windows' = 'install.windows', 'install' = 'installation' How about starting an archive of terms posted into the php.net search box. This will make for some good data which will eventually provide info to expand this feature. On a related note, www.php.net needs a nasty popup that says Choose a mirror!!! ;) Regards, Philip Olson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new php.net shortcuts
I would like to start with a basic list though to put up as an announcement, and prove that this simple thing works too... Sounds good. But, start archiving now and in a few months enough data will exist to make some useful decisions. On a related note, www.php.net needs a nasty popup that says Choose a mirror!!! ;) This is for a long time on our TODO list. Actually a nice automatic mirror chooser, and advice box would be good, and not an annoying popup box IMHO. This will be a nice system. Btw, was kidding about the popup, sometimes I wonder if anyone gets me :) Point is, the fear this will bog down www. even more. Regards, Philip Olson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP_INI USER|PERDIR|SYSTEM|ALL
it'd be uber cool if this got a response or two ;-) Looking through main/main.c it lists many configuration directives as PHP_INI_ALL when in the real world this is not the case. For example, register_globals entry is: STD_PHP_INI_BOOLEAN(register_globals, 1, PHP_INI_ALL, OnUpdateBool, register_globals, php_core_globals, core_globals) When it behaves more like: PHP_INI_PERDIR|PHP_INI_SYSTEM as PHP_INI_USER cannot change this master value. Another example is magic_quote_gpc. Please share some light on this. The config documentation will eventually contain this information and simply harvesting the values from main.c does not seem appropriate. Please explain a little about local/master values too :) Regards, Philip Olson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14131 Updated: include http problem
Someone please briefly explain this behavior. As per the note under remote files in manual: Note: You can't use remote files in include() and require() statements on Windows. Why is that? Regards, Philip Olson On 24 Jan 2002 [EMAIL PROTECTED] wrote: ID: 14131 Updated by: sander Old Summary: include http problem Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows Server 2000 PHP Version: 4.0.6 New Comment: Read the docs. include() and require() do not work on Windows on remote files. Alternative: readfile() Previous Comments: [2002-01-24 11:27:25] [EMAIL PROTECTED] So why not post that as a solution in the first place ?? As we and MOST others download pre compiled binaries to use on our full production sites. [2002-01-24 11:24:51] [EMAIL PROTECTED] Still is a configuration error... You must enable remote includes at compile time. [2002-01-24 11:21:13] [EMAIL PROTECTED] PHP on IIS does not have external includes they just do work. We we posted this before we were told it is a config error, it is not it is an error loclal includes work but not http:// includes even with php as a module on apache. [2001-11-20 03:13:58] [EMAIL PROTECTED] This is most likely a configuration problem. Please ask such questions on [EMAIL PROTECTED] Bogus [2001-11-19 21:34:26] [EMAIL PROTECTED] include (http://www.somesite.com/somepage.html;); Worked perfect on our unix box and our win98 machines but when we installed PHP on our Windows server it no longer worked and tottaly ignored the include unless we used the path instead like. include (somepage.html); [EMAIL PROTECTED] Edit this bug report at http://bugs.php.net/?id=14131edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] FeatureRequest for PHP5
It would be great if it was possible to have CONSTANTS
of types like as Arrays or Objects.
You can already use constant arrays such as array(1, 2, 3)
as constants.
Maybe some day ;)
define('BLAH', array(4,5));
Warning: Constants may only evaluate to scalar values
You can serialize or implode the values ... This is a
decent feature request, submit feature requests to:
http://bugs.php.net
regards,
Philip Olson
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] superglobals and bc
Many ask How do I use superglobals yet allow my scripts to work on older versions of PHP, is there an official documentable response to this? Regards, Philip Olson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] superglobals and bc
The only real thing I think you can document on this is that you can't use superglobals and expect your scripts to work on older versions of PHP. true. We can refer to a faq, one with a hack or two. I mean, you could check php_version() and stick in some extract() calls for older versions wherever you use the superglobals, but that seems rather ugly. Some really want it, let's define the most efficient/least ugly types of hacks :) For example with get, checking phpversion, then appropriatly defining $_GET = $HTTP_GET_VARS. And in a function, do: global $_GET. Now mimicking $_SESSION functionality is another story, eww, maybe that's going too far. Regarding the extract() idea, please clarify a little more. Regards, Philip Olson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] superglobals and bc
Now mimicking $_SESSION functionality is another story, eww, maybe that's going too far. This can be done by a register_shutdown_function() who registers all the vars in $_SESSION, using session_register. That's all :)) If I can understand this new feature correctly (I never used it). LOL, no comment :) Regarding the extract() idea, please clarify a little more. I think Rasmus referred to the register_globals deprecation question, which is another thing IMHO, that need to be documented. Okay that makes sense. Was thinking on the lines of a serialized constant :) There are many user notes coming up about using: extract($_REQUEST); and the like to simluate register_globals. This can be a really bad thing sometimes... Yes it can be. People will continue to do this, we'll need to keep expanding/referring to security.registerglobals: http://www.php.net/manual/en/security.registerglobals.php Regards, Philip Olson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP] Re: [PHP-DEV] Re: strtok bug
BC was broken, this happens sometimes. The majority of the PHP Dev team agrees that strtok() should be POSIX compliant, so it is now, and forever will be. Not being in NEWS/Changelog was an oversight/error, nobody is perfect. This not happening in the future is a desire of everyone. Also, it'll be nice when every BC break is clearly documented in one place, deprecations too. Your desires on the matter are shared by all, in that, allowing for seamless PHP upgrades is a good thing. Such breaks are very uncommon in the PHP world, you will find that some members want many more :)) This is documented now which is as best we can do at this point. That and clearly document all BC breaks in the future. I vow to help on the documentation end. Regards, Philip Olson On Mon, 14 Jan 2002, Manuel Lemos wrote: Hello, I don't disagree, but the fact is that doesn't help anybody that used the function and relied on its original behaviour that was there for 4 years. As for being POSIX compliant, I don't think that POSIX states anything about how PHP functions should behave, so I do not see where is the gain of breaking this function, especially when making PHP strtok behave exactly like C strtok is absolutely irrelevant I think for 99,9% of PHP users because they don't use C in POSIX at all. As a side note, based on the Web browser share distribution of the PHP Classes site, I think the majority of PHP users come from Windows now, but I may be wrong. Anyway, if breaking the behaviour of a long standing function was bad, what really made it worse the was fact that who has broken the function, did not even have the decency to note down in the NEWS/ChangeLog, so whoever plans to upgrade to PHP 4.1.0 could be warned and avoided outages due to this silent backwards incompatible change. Documenting the new behaviour in the user manual does not help even if it was not made much later after releasing PHP 4.1.0 like this change that was only documented because there was a bug report much later after the change was done. What happens is that careful developers tend to take a look in the ChangeLog before installing a new version in a production environment to avoid outages and misbehaviour cause by the change in the broken function. Since it did not happen even until today, nobody is being warned and depending on what the function is used for, it may be causing data trashing of site databases until the developers realize what happened. Don't you have a requirement in the PHP CODING STANDARDS file that makes it mandatory for PHP developers to note down important changes? Not having such requirement just allows messy development habits to jeopardize PHP code quality. Before somebody decides to repress my opinion again, notice how I am trying to be constructive by suggesting improvements in the quality of PHP development process. Now you may put that gun down. :-) Regards, Manuel Lemos -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #15007 Updated: New superglobals not documented
This appears to be a website problem, not a documentation problem. Searching for '$_SERVER' results in matches for 'server', over 2000 of them. If this was a documentation problem, zero results would exist. This is a website problem/feature request. Then its both. Superglobals are NOT documented (yet). If it was documented, will one be able to do a search for _SERVER? HTTP_SERVER_VARS is searchable. I'm not familiar with how the crawling/indexing works. Ideally the over 2,000 results for 'server' wouldn't come up for this. These need to be documented very soon, I'll add them today. The variables.predefined restructuring can wait, I believe Kenneth is working on that. Regards, Philip Olson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #15012: Cannot load libphp4.so - undefined symbol:uncompress
See this faqt: http://www.faqts.com/knowledge_base/view.phtml/aid/5087 Regards, Philip Olson Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/libexec/libphp4.so: undefined symbol: uncompress -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Behaviour of $array1 + $array2
Here's an example of related activities (4.1.1): ?php $a = array(4 = '4 a', 2 = '2 a', 'foo' = 'foo a'); $b = array(4 = '4 b', 1 = '1 b', 'foo' = 'foo b'); $c['plus'] = $a + $b; $c['merge']= array_merge($a,$b); $c['merge_recursive'] = array_merge_recursive($a,$b); $c['concat'] = $a . $b; print_r($c); ? The behavior of . both seems weird yet mostly makes sense too. I agree, the use of '+' needs to be documented. Documented with similarities/differences between array_merge and array_merge_recusive. Some obvious differences can be seen through the above example, who will document this and where? :) I just reported bug #14990 on array_merge_recursive which may be of interest. Without further ado, here's the output from the above code: Array ( [plus] = Array ( [4] = 4 a [2] = 2 a [foo] = foo a [1] = 1 b ) [merge] = Array ( [0] = 4 a [1] = 2 a [foo] = foo b [2] = 4 b [3] = 1 b ) [merge_recursive] = Array ( [0] = 4 a [1] = 2 a [foo] = Array ( [0] = foo a [1] = foo b ) [2] = 4 b [3] = 1 b ) [concat] = ArrayArray ) Regards, Philip Olson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14473 Updated: strtotime wont parse date
just a fyi on why. strtotime obeys the information found here:
http://www.gnu.org/manual/tar-1.12/html_chapter/tar_7.html
so, doing strtotime('Twelfth December 2001'); will work. anyway, fwiw
there you have it :)
regards,
philip olson
On 12 Dec 2001 [EMAIL PROTECTED] wrote:
ID: 14473
Updated by: derick
Reported By: [EMAIL PROTECTED]
Status: Open
Old Bug Type: Date/time related
Bug Type: Feature/Change Request
Operating System: Redhat 7.2
PHP Version: 4.1.0
New Comment:
From the manual:
strtotime -- Parse about any English textual datetime description into a UNIX
timestamp
please note it says any, not all.
Moving this to a feature request.
Derick
Previous Comments:
[2001-12-12 18:36:30] [EMAIL PROTECTED]
strtotime('12th December 2001')
returns -1
The 'th' after the number causes the problem, but this is a perfectly acceptable
date representation and should be recognised I believe.
Edit this bug report at http://bugs.php.net/?id=14473edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14420 Updated: is_file prints stat failed ..message
On 13 Dec 2001 [EMAIL PROTECTED] wrote: Same problem appeared with is_dir() function. In this case I think we should check is_readable(), is_writable() and is_writeable() functions as well. hello vitali, it's fixed now. sterlings commit will be implemented in 4.2.0, from NEWS: - Fixed is_dir(), is_writeable(), is_readable(), is_executable(), is_link() and is_file() functions to not throw a 'file does not exist' warning. (Sterling) http://cvs.php.net/co.php/php4/NEWS patch can be seen here: http://cvs.php.net/diff.php/php4/ext/standard/filestat.c?r1=1.82r2=1.83 for other patches made to filestat.c see: http://bonsai.php.net/cvslog.cgi?file=/php4/ext/standard/filestat.c woohoo! :) regards, philip olson Previous Comments: [2001-12-12 11:38:37] [EMAIL PROTECTED] This is fixed in CVS. --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14367: browscap not well documented
Currently browscap.ini is a front by Cyscape to promote browserHawk. In fact, they often diss on browscap.ini on their website and haven't updated the file since Feb 2000. Back in the good 'ol days it was updated and made more sense, not anymore. A feature request to not use browscap.ini at all exists here: http://bugs.php.net/bug.php?id=4856 This is a very nice feature request :) Regards, Philip Olson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14296 Updated: Undeclared variables and isset()
E_NOTICE:
http://www.php.net/manual/en/phpdevel-errors.php#internal.e-notice
http://www.php.net/manual/en/configuration.php#ini.error-reporting
The following won't create a E_NOTICE level error when $var is not set:
if (isset($var) $var == 'foo') {
echo 'I Love to foo';
}
Could also use a @ but it's not as cool imho :)
if (@$var == 'foo') {
echo 'I love to foo';
}
So as suggested, this depends on your particular settings. Also see the
error_reporting() function.
regards,
Philip Olson
On 30 Nov 2001 [EMAIL PROTECTED] wrote:
ID: 14296
Updated by: hholzgra
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Variables related
Operating System: Win2k
PHP Version: 4.0.6
New Comment:
looks like you have set error_reporting to E_ALL
while you had E_ALL ~E_NOTICE before?
maybe by using php.ini-recommended as template
for php.ini with 4.0.6 while using php.ini-dist
for the former versions?
Previous Comments:
[2001-11-30 04:15:44] [EMAIL PROTECTED]
SYSTEM:
I use PHP 4.0.6 on Win2k pro with Apache 1.3.22 win
Loaded modules don't seem to make a difference for the described behaviour.
DESCRIPION:
Let's say we have a PHP script, the retrieves some variables via HTTP post or get.
And the variables, passed to the script, have different names each time.
Usually we would use isset($variable) to check if it exists. In most cases we need
to check the content of the variable too. So it would be nice to do that in one step.
The script of the following examples retrieved $var1 or $var or both of them via
HTTP.
EXAMPLE 1:
// This would be the usual way i guess
if(isset($var1)){
...
}
if(isset($var2)){
...
}
EXAMPLE 2:
// This has been possible with PHP 3.xx - 4.0.5
// without previously checking for existence
// of $var1/$var2
if($var1 == something){
...
}
if($var2 == anything){
...
}
EXAMPLE 3:
// With PHP 4.0.6 we would have to do this:
if(!isset($var1)){ // is NOT declared?
$var1 = ;
}
if(!isset($var2)){ // is NOT declared?
$var2 = ;
}
// first we had to declare them, now we can use them
if($var1 == something){
...
}
if($var2 == anything){
...
}
I wonder if this new behaviour is a bug or a feature?
Or why can't I find info about it in the changes list if it's a feature?
Please send your answer to: [EMAIL PROTECTED]
Thank you!
Volker Puttrich
Edit this bug report at http://bugs.php.net/?id=14296edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] bug status definition request
hi, What's the difference between open, feedback and analyzed? Seems most discussions leave the bug status as open. philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #13889: FORM variables not passed with php.ini-optimized
i am guessing this is a register_globals issue. see: http://www.php.net/manual/en/configuration.php#ini.register-globals http://www.php.net/manual/en/security.registerglobals.php regards, Philip Olson On 31 Oct 2001 [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.0.6 PHP Bug Type: PHP options/info functions Bug description: FORM variables not passed with php.ini-optimized FORM variables are not passed when php.ini-optimized is used for C:\WINNT\php.ini. The workaround is to use php.ini-dist instead. -- Edit bug report at: http://bugs.php.net/?id=13889edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] karma request - phpweb
Hi! I request karma for module phpweb. Am working with jmcastagnetto on user notes where Voting and User Moderation will be implemented. And will most likely find other things to do, albeit nothing major (yet?). Colin has already done this with the PHP-GTK Manual. i've seen the voting, but not the 'user maintenance' system. will email colin and see how he's doing :) philip ref: http://marc.theaimsgroup.com/?l=phpdocm=99618446902193 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] karma request - phpweb
Hi! I request karma for module phpweb. Am working with jmcastagnetto on user notes where Voting and User Moderation will be implemented. And will most likely find other things to do, albeit nothing major (yet?). Warm Regards, Philip Olson user: philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
