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
[PHP-DEV] CVS Account Request: phallstrom
Need to maintain the application database on gtk.php.net. Andrei Zmievski asked that I request an account. Thanks. -- 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
[PHP-DEV] Bug #15357 Updated: Manual entry for array_shift() incorrect
ID: 15357 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Documentation problem Operating System: Win XP PHP Version: 4.1.0 New Comment: Thank you for this report, this has been fixed in CVS and will show up soon. Previous Comments: [2002-02-03 12:01:55] [EMAIL PROTECTED] In the manual entry for array_shift(), this is stated: This would result in $fruit having 3 elements left:. But it seems that this should be This would result in $stack having 3 elements left:. BTW: I'm not sure if I should report this kind of problems to this bug database, but I couldn't think of another way. Manuzhai Edit this bug report at http://bugs.php.net/?id=15357edit=1 -- 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
[PHP-DEV] Bug #15286 Updated: ucwords doesn't work with capitalized string
ID: 15286 Updated by: philip Old Summary: ucwords doesn't work with capitalized string Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: Strings related Operating System: Win2K SP2 PHP Version: 4.1.1 New Comment: This is expected behavior, not a bug. $str = 'McDonalds'; You want ucwords($str) to result in Mcdonalds? If so, use strtolower() first as the documentation suggests. Previous Comments: [2002-01-29 17:44:56] [EMAIL PROTECTED] $propercompany = ucwords(WOLF PACK TRADERS); $propercompany should be Wolf Pack Traders I am running PHP v4.1.1 with: System Windows NT 5.0 build 2195 Build Date Dec 30 2001 Server API CGI Virtual Directory Support enabled Configuration File (php.ini) Path C:\WINNT\php.ini ZEND_DEBUG disabled Thread Safety enabled And using IIS 5.0 I know that this problem is mentioned in the documentation but I did not find an actual bug report when I searched the bug database to actually have it fixed. Jim Ekleberry Edit this bug report at http://bugs.php.net/?id=15286edit=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-DEV] Bug #8685 Updated: Here-Syntax problem
ID: 8685 Updated by: philip Reported By: [EMAIL PROTECTED] Old Status: Closed Status: Open Bug Type: Feature/Change Request PHP Version: 4.0.4 New Comment: I like this feature request, so am reopening it :) Until someone replies with a definitive response as to why such heredoc spacing is required in PHP. Previous Comments: [2002-01-28 20:38:20] [EMAIL PROTECTED] Many script languages that support here doc syntax require closing tag at col 1. Won't change. [2001-01-12 16:36:11] [EMAIL PROTECTED] This is not a bug, but a feature request [2001-01-12 16:22:11] [EMAIL PROTECTED] why must the closing tag be in column 1 ? i think it schould be enought that it stays in its own line. if($foo) { echo EOF ... lots of text ... EOF; } looks very ugly and messes up all code beautifiers and autoindention. Edit this bug report at http://bugs.php.net/?id=8685edit=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]
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]
[PHP-DEV] Bug #12151 Updated: http://www.php.net/FAQ.php#6.11 discrepancy
ID: 12151 Updated by: philip Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Documentation problem Operating System: Solaris 8 4/01 PHP Version: 4.0.6 New Comment: Modified in CVS. Previous Comments: [2001-07-14 05:14:31] [EMAIL PROTECTED] This is the responsibility of the docteam now [2001-07-13 16:13:44] [EMAIL PROTECTED] When I configured tried to configure mod_dav, it complained that apxs (1.3.20) was broken, and referred me to your FAQ. You suggest that the three lines below might have values of ' ', which isn't quite what I saw (all three were 'q()' in my copy). Don't know if this is a 1.3.20 change, or if I have a different problem, but wanted to report it. I did make your change, and mod_dav configured compiled, so looks good so far. my $CFG_CFLAGS_SHLIB = q(); # substituted via Makefile.tmpl my $CFG_LD_SHLIB = q(); # substituted via Makefile.tmpl my $CFG_LDFLAGS_SHLIB = q(); # substituted via Makefile.tmpl Edit this bug report at http://bugs.php.net/?id=12151edit=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-DEV] Bug #15228: variable variable spacing
From: [EMAIL PROTECTED] Operating system: n/a PHP version: 4.0CVS-2002-01-25 PHP Bug Type: Scripting Engine problem Bug description: variable variable spacing The following should result in a parse error: $foo = 'bar'; $bar = 'hello'; print $ $foo; // hello print $$foo; // hello Instead, 'hello' is printed both times. -- Edit bug report at: http://bugs.php.net/?id=15228edit=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]
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] Bug #15108: Server variables to exist globally w/ register_globals = off
From: [EMAIL PROTECTED] Operating system: n/a PHP version: 4.1.1 PHP Bug Type: Feature/Change Request Bug description: Server variables to exist globally w/ register_globals = off In short, when register_globals = off, server variables would/should continue to register globally. Variables such as: $PHP_SELF, $DOCUMENT_ROOT, $REMOTE_ADDR, etc. As currently they do not. And on a sidenote, the current docs imply that server variables always exist, regardless of setting. Some possible options: a) Create a new config setting, such as register_server_globals or register_predefined_globals b) Make register_globals allow for individual EGPCS settings (default to S) c) Make server variables always exist, like track_vars do now. d) ... This will help ease the register_globals = off transition as well as cause a lot less 4.2.0 BROKE PHP!!! emails. But most importantly, this will be useful. -- Edit bug report at: http://bugs.php.net/?id=15108edit=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-DEV] Bug #15108 Updated: Server variables to exist globally w/ register_globals = off
ID: 15108 Updated by: philip Reported By: [EMAIL PROTECTED] Old Status: Bogus Status: Feedback Bug Type: Feature/Change Request Operating System: n/a Old PHP Version: 4.1.1 PHP Version: 4.2.0 New Comment: After some searching, came across an important thread that my brain never saw. The proposal on the issue of register_globals and the big change: http://marc.theaimsgroup.com/?l=php-devm=99638397319055 Which includes some great information. Including import_globals(), which in short, my concern is solved by: import_globals('S'). This next thread (very long) is very related too, which existed before the above proposal: http://marc.theaimsgroup.com/?l=php-devm=99600275103594 It's all sounds good. But :) Throughout the history of the manual, it's been *implied* that predefined server variables are registered globally. This will obviously change (see #14472) but point is, this is a potential problem. Is this worth doing anything else about? Like, defaulting PHP with 'S' (or ES) for a release or two? Or, would that just add unneeded confusion. Previous Comments: [2002-01-18 16:52:14] [EMAIL PROTECTED] But most importantly, this will be useful. no it won't, same security consideration as with the other global registrations [2002-01-18 16:14:25] [EMAIL PROTECTED] In short, when register_globals = off, server variables would/should continue to register globally. Variables such as: $PHP_SELF, $DOCUMENT_ROOT, $REMOTE_ADDR, etc. As currently they do not. And on a sidenote, the current docs imply that server variables always exist, regardless of setting. Some possible options: a) Create a new config setting, such as register_server_globals or register_predefined_globals b) Make register_globals allow for individual EGPCS settings (default to S) c) Make server variables always exist, like track_vars do now. d) ... This will help ease the register_globals = off transition as well as cause a lot less 4.2.0 BROKE PHP!!! emails. But most importantly, this will be useful. Edit this bug report at http://bugs.php.net/?id=15108edit=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-DEV] Bug #14992 Updated: Behaviour of $array = $array1 + $array2; not documented
ID: 14992 Updated by: philip Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem PHP Version: 4.1.1 New Comment: We know, but it needs to be documented nevertheless. I posted a rather detailed test. The question is where to document it exactly. Previous Comments: [2002-01-16 12:53:08] [EMAIL PROTECTED] $array1 + $array2 is *not* the same as array_merge(). See for yourself with array(1, 2) and array(5, 6, 7). [2002-01-11 06:03:44] [EMAIL PROTECTED] Where should this feature be documented, I see two viable options: a) Under array_merge() b) A new Array Operators man page. I assume most people wanting to merge arrays will go to array_merge() but having it's own man page could make room to clearly explain the differences of it and array_merge and array_merge_recursive. I vote for (b). Of course the functions would link to it. This is kinda like how `backticks` are documented now, as, Execution Operators. A brief note under Arithmetic Operators may be appropriate too. Also, for those interested in documenting this beast, please see this post: http://marc.theaimsgroup.com/?l=phpdocm=101074306518514 [2002-01-11 05:04:53] [EMAIL PROTECTED] The behaviour of the following code doens't seem to be documented: ? $foo = array(27 = 'Ene'); $bar = array(-1 = 'Mene'); $baz = $foo + $bar; var_dump($baz); ? array(2) { [27]= string(3) Ene [-1]= string(4) Mene } Edit this bug report at http://bugs.php.net/?id=14992edit=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-DEV] Bug #15007 Updated: New superglobals not documented
ID: 15007 Comment by: [EMAIL PROTECTED] Old Reported By: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Duplicate Bug Type: Website problem Operating System: N/A PHP Version: 4.1.1 New Comment: The _ in _SERVER get's ignored. _SERVER_ is the same, 553 of unrelated results (I swear it was 2000 before :). HTTP_SERVER_VARS works fine. Someone here knows htdig, maybe can adjust? I assume $_SERVER is somewhere in the online manual user comments. The info in the manual CVS now but the manual has some build difficulties currently. Regardless, _SERVER != SERVER. Maybe making such an adjustment will cause other problems? This is a duplicate, in that imho it's a feature request to add custom go words to the search mechanism. Ideally, we can create a list of words and where they should point to in manual upon the search. Working with a list of popular searches will be helpful too. Previous Comments: [2002-01-15 07:15:41] [EMAIL PROTECTED] Dupe of #14378 [2002-01-13 06:25:10] [EMAIL PROTECTED] Please use _SERVER as your search term. $ may be special for htdig. [2002-01-12 17:09:53] [EMAIL PROTECTED] 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. [2002-01-12 16:55:15] [EMAIL PROTECTED] Reclassified, reopened. [2002-01-12 16:46:10] [EMAIL PROTECTED] I appreciate you're working on the _* documentation, but the problem remains there is no way to search for $_SERVER and get results that contain the exact string 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/?id=15007 Edit this bug report at http://bugs.php.net/?id=15007edit=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-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] Bug #5919 Updated: stri_replace() to compliment str_replace()
ID: 5919 Comment by: [EMAIL PROTECTED] Old Reported By: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Feature/Change Request Operating System: Slackware Linux 7.0 PHP Version: 4.0.0 New Comment: Please submit this patch :) Previous Comments: [2001-05-07 10:57:33] [EMAIL PROTECTED] Closing because of no feedback [2000-11-21 04:04:24] [EMAIL PROTECTED] Where's the patch? =) [2000-09-23 18:40:41] [EMAIL PROTECTED] A patch that implements this feature will probably accepted In that case I'll start writing a patch :-) [2000-09-16 01:18:16] [EMAIL PROTECTED] A patch that implements this feature will probably accepted. That is when it's nicely written of course. [2000-08-02 12:33:30] [EMAIL PROTECTED] It would be extremely nice to have a case insensitive version of str_replace() so that you don't have to use the much slower eregi_replace() when you need to replace strings of mixed case. I believe a logical name for such a function would be stri_replace() If there are no current plans to implement such a feature, would a patch that implements it be accepted? Best regards, Jesper Juhl [EMAIL PROTECTED] Edit this bug report at http://bugs.php.net/?id=5919edit=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-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]
[PHP-DEV] Bug #14472 Updated: predefined variables update
ID: 14472 Updated by: philip Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: n/a PHP Version: 4.1.0 New Comment: Other notes: a) Document the $_SESSION special features b) Move non-PHP variables to appendix, as discussed on list http://marc.theaimsgroup.com/?l=phpdocm=101009675307286 Previous Comments: [2001-12-12 18:06:29] [EMAIL PROTECTED] The Predefined Variables section of the manual needs some work, here are some thoughts: (a) Document that register_globals affects environment variables. For example, if register_globals is turned off then to access DOCUMENT_ROOT one needs to do $HTTP_SERVER_VARS['DOCUMENT_ROOT'] as $DOCUMENT_ROOT will not work. Also, use of getenv() is available, and now $_SERVER... This is an important point. Removing the $ in the description term's seems appropriate too (b) Link to security.registerglobals (c) Link commandline to commandline docs (d) Remove specific reference to php3/apache 1.3.6 (e) List new 4.1.0 variables, keep seperate from the others (for now) (f) Mention of register_argc_argv near $argc $argv (g) Expand docs on difference between ENV and SERVER variables (h) Add a See also: predefined constants and getenv() (i) Briefly document the affect of variable scope (j) Mention $GLOBALS (k) Between SCRIPT_NAME, PATH_INFO, PHP_SELF and REQUEST_URI, which are available when (cgi vs. mod) and why windows users sometimes get php.exe (l) Go through user notes, implement/delete as appropriate Related doc bugs are #11833, #14093 and #14260 Edit this bug report at http://bugs.php.net/?id=14472edit=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-DEV] Bug #15007 Updated: New superglobals not documented
ID: 15007 Updated by: philip Reported By: [EMAIL PROTECTED] Status: Open Old Bug Type: Documentation problem Bug Type: Website problem Operating System: N/A PHP Version: 4.1.1 New Comment: 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. Previous Comments: [2002-01-12 16:55:15] [EMAIL PROTECTED] Reclassified, reopened. [2002-01-12 16:46:10] [EMAIL PROTECTED] I appreciate you're working on the _* documentation, but the problem remains there is no way to search for $_SERVER and get results that contain the exact string [2002-01-12 16:35:07] [EMAIL PROTECTED] yes, we are aware of this, and documentation people are working on documentation for _* global variables. Thanks. [2002-01-12 15:33:43] [EMAIL PROTECTED] I've seen the new $_SERVER (for example) variable arrays mentioned, as replacements for the old $HTTP_SERVER_VARS (I think) array, but I wasn't able to easily find any pages that mention them. I therefore put $_SERVER (no quotes) in the search box, and got pages with the word server, not $_SERVER so I tried entering $_SERVER (a quoted string), which produced the same results. Problems: 1. It appears there is no way to find pages with the exact text $_SERVER using this search system. 2. Discussion of $_SERVER (and $POST, $_ENV, etc.) arrays needs to be findable in the documentation. Edit this bug report at http://bugs.php.net/?id=15007edit=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]
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]
[PHP-DEV] Bug #14990: array_merge_recursive modifies inputted value
From: [EMAIL PROTECTED] Operating system: n/a PHP version: 4.1.1 PHP Bug Type: Arrays related Bug description: array_merge_recursive modifies inputted value In Summary: -- array_merge_recursive() modifies the array entered as the second parameter if the merged arrays have at least one identical stringed key. It will affect all such duplicate keys, and modify the second parameter's array as demonstrated below. Example: -- ?php $a = array(2 = '2 a', 'foo' = 'foo a','bar' = 'bar a'); $b = array(2 = '2 b', 'foo' = 'foo b','bar' = 'bar b'); $c['recursive'] = array_merge_recursive($a,$b); $c['a'] = $a; $c['b'] = $b; print_r($c); ? Example output: --- Array ( [recursive] = Array ( [0] = 2 a [foo] = Array ( [0] = foo a [1] = foo b ) [bar] = Array ( [0] = bar a [1] = bar b ) [1] = 2 b ) [a] = Array ( [2] = 2 a [foo] = foo a [bar] = bar a ) [b] = Array ( [2] = 2 b [foo] = Array ( [0] = foo b ) [bar] = Array ( [0] = bar b ) ) ) Notes: Notice how in $b, keys 'foo' and 'bar' are now arrays when initially they were not. This behavior exists with all such duplicate stringed keys. array_merge_recursive() should not directly affect inputted values. This seems related to bug #14128. -- Edit bug report at: http://bugs.php.net/?id=14990edit=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-DEV] Bug #14990 Updated: array_merge_recursive modifies inputted value
ID: 14990 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Arrays related Operating System: n/a PHP Version: 4.1.1 New Comment: With 3+ parameters, only the first parameter is left untouched. All others are affected, as demonstrated above with $b. Previous Comments: [2002-01-11 04:02:21] [EMAIL PROTECTED] In Summary: -- array_merge_recursive() modifies the array entered as the second parameter if the merged arrays have at least one identical stringed key. It will affect all such duplicate keys, and modify the second parameter's array as demonstrated below. Example: -- ?php $a = array(2 = '2 a', 'foo' = 'foo a','bar' = 'bar a'); $b = array(2 = '2 b', 'foo' = 'foo b','bar' = 'bar b'); $c['recursive'] = array_merge_recursive($a,$b); $c['a'] = $a; $c['b'] = $b; print_r($c); ? Example output: --- Array ( [recursive] = Array ( [0] = 2 a [foo] = Array ( [0] = foo a [1] = foo b ) [bar] = Array ( [0] = bar a [1] = bar b ) [1] = 2 b ) [a] = Array ( [2] = 2 a [foo] = foo a [bar] = bar a ) [b] = Array ( [2] = 2 b [foo] = Array ( [0] = foo b ) [bar] = Array ( [0] = bar b ) ) ) Notes: Notice how in $b, keys 'foo' and 'bar' are now arrays when initially they were not. This behavior exists with all such duplicate stringed keys. array_merge_recursive() should not directly affect inputted values. This seems related to bug #14128. Edit this bug report at http://bugs.php.net/?id=14990edit=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]
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]
[PHP-DEV] Bug #14938 Updated: No htmlescape() function for PHP4
ID: 14938 Updated by: philip Reported By: [EMAIL PROTECTED] Old Status: Closed Status: Duplicate Bug Type: Documentation problem Operating System: Linux PHP Version: 4.1.1 Assigned To: imajes New Comment: Be sure to discuss this with Zak, see bug #14418 which stemmed from this htmlescape() doc bug, not sure where he's at on it. I'm sure he wouldn't mind if you did a commit though :) Previous Comments: [2002-01-08 19:34:35] [EMAIL PROTECTED] thanks, that's fixed. [2002-01-08 18:43:21] [EMAIL PROTECTED] i'm a sucker for punishment. [2002-01-08 18:36:18] [EMAIL PROTECTED] You can use htmlspecialchars() htmlentities(). Filled as a documentation problem. [2002-01-08 17:29:58] [EMAIL PROTECTED] As you can find PHP Faq at:http://www.php.net/manual/en/faq.html.php, there is a function of htmlescape() to escape string for html syntax. unfortunately, i can not find htmlescape() function from php function table, and wonder what is going on here. would you kindly please let me about it? thanx a ton! Jackey Edit this bug report at http://bugs.php.net/?id=14938edit=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-DEV] Bug #11833 Updated: Unsufficient docs
ID: 11833 Updated by: philip Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Documentation problem Operating System: any PHP Version: 4.0.6 Assigned To: danbeck New Comment: This is essentially a duplicate, see bug #14472 for a more exaustive report. Anyone want to tackle it? :-) Regarding #11833, essentially this man page is geared towards register_globals = on when it shouldn't be. Previous Comments: [2002-01-02 19:42:07] [EMAIL PROTECTED] No feedback. [2001-07-03 10:28:12] [EMAIL PROTECTED] Assigning this to myself. (I must love the pain...) [2001-07-02 10:21:56] [EMAIL PROTECTED] It's very hard to understand what you are saying... please forgive us if we don't quite get your point. Are you saying that the documentation is not clear as to which variables you can access using the $HTTP_ENV_VARS and $HTTP_SERVER_VARS. If this is what you are asking, then please read the 3rd paragraph and the note that follows at: http://php.net/manual/en/language.variables.predefined.php The manual can not be an exhaustive resource for all predefined variables. The best way to see exactly what is available to you is the check the output of the phpinfo() function. It describes everthing you would need to know about the PHP environment and it's predefined variables in gratuitous detail. Also, you specifically mention $PHP_SELF. You say that it's not intuitive to be in HTTP_SERVER_VARS? But it is.. it has noting to do with the system environment ($HTTP_ENV_VARS), but everything to do with the server environment. It's the filename part of the URI, not the actual filename on the server. [2001-07-02 07:13:33] [EMAIL PROTECTED] I don't agree. I just disable register_global by setting it Off. Now I can't acces simply $PHP_SELF - returned string is empty. When I get $HTTP_SERVER_VARS[PHP_SELF], the return string is such as the $PHP_SELF with register_global On. Maybe it isn't docs bug, but devel bug? [2001-07-02 07:06:16] [EMAIL PROTECTED] $PHP_SELF is not an environment variable, nor a server variable, it is a special PHP variable, so it wont be registered in any arrays you listed 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/?id=11833 Edit this bug report at http://bugs.php.net/?id=11833edit=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-DEV] Bug #14493: MySQL socket detection
From: [EMAIL PROTECTED] Operating system: Unix (FreeBSD) PHP version: 4.0.6 PHP Bug Type: *Configuration Issues Bug description: MySQL socket detection START--- #!/bin/sh $VER_PHP=4.0.6 $PREFIX=/usr/home/src LD_LIBRARY_PATH=$PREFIX/mm/lib:$PREFIX/openssl/lib fetch -mva http://download.php.net/distributions/php-$VER_PHP.tar.gz gtar -xvzof php-$VER_PHP.tar.gz cd php-$VER_PHP ./configure --with-apxs=$PREFIX/apache/bin/apxs \ --enable-safe-mode --enable-calendar \ --enable-filepro --enable-ftp --enable-trans-sid \ --enable-sockets --enable-inline-optimization \ --with-openssl=$PREFIX/openssl --with-mysql=$PREFIX/mysql \ --with-iodbc=$PREFIX/iodbc --with-mm=$PREFIX/mm \ END- configure output: [snipped] checking for MySQL support... yes checking for MySQL UNIX socket... /tmp/mysql.sock patched configure output: checking for MySQL support... yes checking for MySQL UNIX socket... /usr/home/src/mysql/mysql.sock Patch: sduwebship# diff -crN configure.old configure *** configure.old Thu Dec 13 15:43:37 2001 --- configure Thu Dec 13 15:44:53 2001 *** *** 29538,29554 echo $ac_n checking for MySQL UNIX socket... $ac_c 16 echo configure:29541: checking for MySQL UNIX socket 5 ! MYSQL_SOCK=/tmp/mysql.sock ! for i in \ ! /var/run/mysqld/mysqld.sock \ ! /var/tmp/mysql.sock \ ! /var/lib/mysql/mysql.sock \ ! /var/mysql/mysql.sock \ ! ; do ! if test -r $i; then ! MYSQL_SOCK=$i ! fi ! done cat confdefs.h EOF #define MYSQL_UNIX_ADDR $MYSQL_SOCK EOF --- 29538,29544 echo $ac_n checking for MySQL UNIX socket... $ac_c 16 echo configure:29541: checking for MySQL UNIX socket 5 ! MYSQL_SOCK=`$MYSQL_DIR/bin/mysql_config --socket` cat confdefs.h EOF #define MYSQL_UNIX_ADDR $MYSQL_SOCK EOF -- Edit bug report at: http://bugs.php.net/?id=14493edit=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]
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]
[PHP-DEV] Bug #14472: predefined variables update
From: [EMAIL PROTECTED] Operating system: n/a PHP version: 4.1.0 PHP Bug Type: Documentation problem Bug description: predefined variables update The Predefined Variables section of the manual needs some work, here are some thoughts: (a) Document that register_globals affects environment variables. For example, if register_globals is turned off then to access DOCUMENT_ROOT one needs to do $HTTP_SERVER_VARS['DOCUMENT_ROOT'] as $DOCUMENT_ROOT will not work. Also, use of getenv() is available, and now $_SERVER... This is an important point. Removing the $ in the description term's seems appropriate too (b) Link to security.registerglobals (c) Link commandline to commandline docs (d) Remove specific reference to php3/apache 1.3.6 (e) List new 4.1.0 variables, keep seperate from the others (for now) (f) Mention of register_argc_argv near $argc $argv (g) Expand docs on difference between ENV and SERVER variables (h) Add a See also: predefined constants and getenv() (i) Briefly document the affect of variable scope (j) Mention $GLOBALS (k) Between SCRIPT_NAME, PATH_INFO, PHP_SELF and REQUEST_URI, which are available when (cgi vs. mod) and why windows users sometimes get php.exe (l) Go through user notes, implement/delete as appropriate Related doc bugs are #11833, #14093 and #14260 -- Edit bug report at: http://bugs.php.net/?id=14472edit=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-DEV] Bug #13911 Updated: Documentation on ini_set could use some reorganizing
ID: 13911 Updated by: philip Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Any PHP Version: 4.0.6 New Comment: What about integrating the contents of this useful table into a new (and improved) version of config.xml ? My only concern is config may then seem bloated (ie. too much information). But, if layed out nicely it could be beautiful! :) Btw, config.xml lists configuration options alphabetically (within given sections), if not integrated then, imho, ini_set listings should be too. Previous Comments: [2001-12-12 18:04:31] [EMAIL PROTECTED] I'm looking at the output of phpinfo() for 4.0.6 (Not sure about 4.1 which was just released) and all the directives *are* listed in alphabetical order, e.g. allow_call_time_pass_reference, allow_url_fopen, arg_separator.input, arg_separator.output, etc. all the way down to y2k_compliance. [2001-12-12 17:55:21] [EMAIL PROTECTED] they are sortet in the way phpinfo() shows them. If we change it here IMHO phpinfo needs to be changed as well. what about reorganizing the phpinfo()output to be sorted alphabetically. [2001-11-02 16:44:05] [EMAIL PROTECTED] The table that describes the configuration options on http://www.php.net/manual/en/function.ini-set.php suffers from a small but annoying usability problem: the options aren't sorted in any logical order. It would maybe make sense to have the configuraion options listed in alphabetical order to make it easier to scan the list in order to find a certain option. Some nice source code formatting to the pages would be nice, too. Check out the code for the table that lists the options and you'll see what I mean. If anyone else doesn't want to take the time to do it, I could fix the table myself and submit it. Edit this bug report at http://bugs.php.net/?id=13911edit=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-DEV] Bug #14411 Updated: php-4.1.0.tar.gz CRC verify error
ID: 14411 Updated by: philip Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Documentation problem Operating System: open server 5 PHP Version: 4.1.0 New Comment: fixed, try again. Previous Comments: [2001-12-10 15:12:25] [EMAIL PROTECTED] php-4.1.0.tar.gz download file CRC verify error. Edit this bug report at http://bugs.php.net/?id=14411edit=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-DEV] Bug #14299 Updated: explode() case sensitivity.
ID: 14299 Updated by: philip Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Documentation problem Operating System: Linux PHP Version: 4.0.6 New Comment: closed. Previous Comments: [2001-11-30 15:05:38] [EMAIL PROTECTED] Strings are case sensitive. Kinda like: if ($var == 'Bar') will return false if $var = 'bar'. Maybe because explode() is such a commonly used function, this could be mentioned here (that it's case sensitive). But doing so may open up a large can of worms (having to document this everywhere). I vote -.5 on implementing this. At first glance I don't see strings being case sensitive mention in the types.string section, maybe it should be. [2001-11-30 11:01:44] [EMAIL PROTECTED] I recently added a note to http://www.php.net/explode and was informed that I should probably post it here. Original Note: I'm not sure if this is intentional, but there is no indication whether explode() is case insensitive. I ended up having to convert my strings and keywords to lowercase using strtolower() in order to do this. I'm using 4.0.4, FWIW. I don't care one way or another if this is a bug or a documentation error since I was able to work around it, but I think other people may get confused when it fails to explode because there's no info about case sensitivity. Thanks, Stephen VanDyke [EMAIL PROTECTED] Edit this bug report at http://bugs.php.net/?id=14299edit=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-DEV] Bug #12868 Updated: Appendix G Descrepancies..
ID: 12868 Updated by: philip Reported By: [EMAIL PROTECTED] Old Status: Assigned Status: Open Bug Type: Documentation problem Operating System: win32 PHP Version: 4.0.6 Assigned To: jeroen New Comment: This seems okay now. But, maybe the alias appendix should be auto-generated via something like genaliasindex ? Previous Comments: [2001-08-21 13:35:12] [EMAIL PROTECTED] It doesn't matter at all indeed. For chop/rtrim: chop used to be main function, but since it's in perl and behaving differently over there, _and_ rtrim is consistent with trim and ltrim, I decided to document chop as the alias. Will update aliases.xml too. I recently suggested a better indication to aliases (in phpdoc/README - CONVENTIONS), but that hasn't been implemented yet - be patient. Btw: is_float will be master now, is_double the alias... PHP doesn't have double-precision floats, there's only one flavour. [2001-08-21 01:28:38] [EMAIL PROTECTED] Update status... [2001-08-21 01:28:13] [EMAIL PROTECTED] I don't understand why it matters which is the 'master' and which is the alias? I would guess that the reason for the inconsistency in the documentation is that it really doesn't matter which is which, so the doc team is not all that careful about it. But that's just a guess...this wouldn't be all that hard to clear up. FWIW, rtrim() is an alias to chop() and fputs() is an alias to fwrite(). [2001-08-21 00:12:18] [EMAIL PROTECTED] This is truly a followup to my previous post - message about what appears to be descrepancies in Appendix G.. which has further some confusion as to which functions are truly an alias and which is the master function.. I guess I need to understand what the master function is supposed to be, and what an alias is supposed to be. Perhaps I have these backwards, and thus the confusion, but some of this doesn't quite set right.. The first function in the list (chop) is labeled as the master function, and it's alias as (rtrim).. but when you go to the master function, (chop) it's documentation indicates it's the alias. and to see rtrim for details. There are some functions in this list like - fwrite() and fputs() - where fwrite is labled as the master and fputs the alias.. while the documentaion for both functions do not indicate either as an alias.. This goes on.. naturally some of these make perfect sense, if you looke at is_double() marked as a master - having aliases of is_float() and is_real().. the documentation corresponds perfectly.. i.e. if you call up is_float() or is_real() it directs you to is_double().. which brings some understanding back. and jives with what I would preceive as the relationship between a master function and an alias. Input on this matter would greatly be appreciated.. thanks a bunch. Edit this bug report at http://bugs.php.net/?id=12868edit=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]
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]
[PHP-DEV] Bug #14130 Updated: xml in zlib.xml does not use CDATA for code
ID: 14130 Updated by: philip Reported By: [EMAIL PROTECTED] Old Status: Assigned Status: Closed Bug Type: Documentation problem Operating System: linux PHP Version: 4.0CVS-2001-11-19 Assigned To: hholzgra New Comment: hholzgra CDATA conversions are complete. I labeled a few finishing touches as Fix typos when they weren't really true typos. Sorry. But, everything should be good now :) Previous Comments: [2001-11-20 04:13:51] [EMAIL PROTECTED] all examples in en/functions/ up to mbstring.xml have already been converted, the rest will follow soon [2001-11-19 22:01:24] [EMAIL PROTECTED] Not all examples have a CDATA section. [2001-11-19 20:53:01] [EMAIL PROTECTED] patch below regards alan Index: zlib.xml === RCS file: /repository/phpdoc/en/functions/zlib.xml,v retrieving revision 1.19 diff -u -r1.19 zlib.xml --- zlib.xml10 Nov 2001 21:49:42 - 1.19 +++ zlib.xml20 Nov 2001 01:51:21 - @@ -40,11 +40,11 @@ /para example titleSmall Zlib Example/title -programlisting role=php -lt;?php +programlisting role=php![CDATA[ +?php $filename = tempnam ('/tmp', 'zlibtest').'.gz'; -print lt;html\nlt;headlt;/head\nlt;body\nlt;pre\n; +print html\nhead/head\nbody\npre\n; $s = Only a test, test, test, test, test, test, test, test!\n; // open file for writing with maximum compression @@ -72,10 +72,10 @@ echo Error with zlib functions!; } unlink($filename); -print lt;/pre\nlt;/h1lt;/body\nlt;/html\n; +print /pre\n/h1/body\n/html\n; ? - /programlisting + ]]/programlisting /example /sect1 /partintro Edit this bug report at http://bugs.php.net/?id=14130edit=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-DEV] Bug #14305 Updated: type-o on web site
ID: 14305 Updated by: philip Reported By: [EMAIL PROTECTED] Old Status: Bogus Status: Closed Bug Type: Documentation problem Operating System: Win2k PHP Version: 4.1.0 New Comment: Reworded this entity in language-snippets.ent a bit (it affects all such warnings). Please don't get so worked up next time, we appreciate your concerns. Previous Comments: [2001-12-06 06:40:00] [EMAIL PROTECTED] Quote: IMO it's good as it is right now. You must not speak English very well, that or you have no writing ability what-so-ever! Dude, concreto is not even a word in English and the sentance is a meaningless mess! If you are not going to do anything about the problem, at least don't answer ignorantly, sheesh. So much for open-source contributions... [2001-12-06 06:18:10] [EMAIL PROTECTED] IMO it's good as it is right now. [2001-11-30 15:17:20] [EMAIL PROTECTED] http://download.php.net/manual/en/ref.overload.php has a type-o in the wanring, search for the word concreto I can't tell actually what the typist meant to say, but probably needs to replace: names, in concreto ANYTHING with: names and ANYTHING Edit this bug report at http://bugs.php.net/?id=14305edit=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]
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 #14299 Updated: explode() case sensitivity.
ID: 14299 Updated by: philip Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Documentation problem Operating System: Linux PHP Version: 4.0.6 New Comment: Strings are case sensitive. Kinda like: if ($var == 'Bar') will return false if $var = 'bar'. Maybe because explode() is such a commonly used function, this could be mentioned here (that it's case sensitive). But doing so may open up a large can of worms (having to document this everywhere). I vote -.5 on implementing this. At first glance I don't see strings being case sensitive mention in the types.string section, maybe it should be. Previous Comments: [2001-11-30 11:01:44] [EMAIL PROTECTED] I recently added a note to http://www.php.net/explode and was informed that I should probably post it here. Original Note: I'm not sure if this is intentional, but there is no indication whether explode() is case insensitive. I ended up having to convert my strings and keywords to lowercase using strtolower() in order to do this. I'm using 4.0.4, FWIW. I don't care one way or another if this is a bug or a documentation error since I was able to work around it, but I think other people may get confused when it fails to explode because there's no info about case sensitivity. Thanks, Stephen VanDyke [EMAIL PROTECTED] Edit this bug report at http://bugs.php.net/?id=14299edit=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-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]
[PHP-DEV] Bug #10172 Updated: get_class() doesn't return lowercase for DomX objects
ID: 10172 Updated by: philip Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Documentation problem Operating System: RH 7.0 PHP Version: 4.0 Latest CVS (04/04/2001) New Comment: Seems strange. Docs have been updated to reflect current behavior. Changing status to 'feedback'. Previous Comments: [2001-11-22 11:08:41] [EMAIL PROTECTED] Well, I suppose it is a documentation problem of sorts ... but my preference would be for the get_class() function to be consistent, regardless of whether the class is user-defined or extention-defined. Any reason why this shouldn't be consistent? - Colin [2001-11-21 19:35:55] [EMAIL PROTECTED] get_class() only returns user defined classes in lowercase. Classes defined in extensions are returned in their original notation. Making this a documentation problem. [2001-04-04 20:41:34] [EMAIL PROTECTED] get_class() is documented to return the class/object name in lowercase. This isn't the case for DomText, DomDocument, etc. objects. In these cases, get_class() returns the StudyCaps version of the object name. - Colin Edit this bug report at http://bugs.php.net/?id=10172edit=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]