#32594 [Opn]: missing dll in download
ID: 32594 Updated by: [EMAIL PROTECTED] Reported By: mazdaf at yahoo dot com Status: Open -Bug Type: Documentation problem +Bug Type: Other web server Operating System: win 2003 PHP Version: Irrelevant New Comment: Not a docproblem. Previous Comments: [2005-04-05 19:11:46] mazdaf at yahoo dot com Description: In the install file, it says The directory structure extracted from the zip is different for PHP versions 4 and 5 and look like as follows: Example 2-1. PHP 4 package structure +--sapi-- SAPI (server module support) DLLs | | | |-php4activescript.dll | | | |-php4apache.dll | | | |-php4apache2.dll | | | |-.. --- but there is no php4activescript.dll file in the 4.3.11 download in the Windows Binaries/PHP 4.3.11 zip package [7,289Kb] - 31 Mar 2005 download. -- Edit this bug report at http://bugs.php.net/?id=32594&edit=1
#30115 [WFx->Opn]: The wrong link is shown for __destruct() when using phpmanual
ID: 30115 Updated by: [EMAIL PROTECTED] Reported By: richard dot quadling at bandvulc dot co dot uk -Status: Wont fix +Status: Open -Bug Type: Documentation problem +Bug Type: Unknown/Other Function Operating System: n/a PHP Version: all New Comment: Special methods need special handling. I guess PHP developers would not like the docs to have the __destruct() function(!) documented with a dumb page, so the error reporting code should be able to detect if it is about a special OO function, and should direct to the right doc page IMHO. Previous Comments: [2004-09-20 18:50:25] [EMAIL PROTECTED] The problem is that we don't have a function ID for the __destruct() method (and won't have this). PHP will generate valid links for almost every function, but it won't work for OOP methods, as they are documented in a different place (language reference chapter). As PHP can't imagine where every single function is documented, this won't be fixed (any other php member speak if is against!). [2004-09-20 09:10:21] richard dot quadling at bandvulc dot co dot uk What criteria is used to ID a bug report as bogus? I said "Documentation problem". You say it IS documented, but not with regards to the phpmanual facility activated within PHP.INI? I'm using the latest HTML manuals available (28-8-2004). There is no page called function.--destuct.html in the archive available from www.php.net. I do not see how this is bogus? Richard Quadling. [2004-09-18 12:51:09] [EMAIL PROTECTED] The __destruct() method is documented. [2004-09-16 15:15:47] richard dot quadling at bandvulc dot co dot uk Description: I use the phpmanual facility so that I can get links to the function that fails, when it fails. My code failed showing ... Warning: FormMaint::__destruct() [function.--destruct.html]: message: Cannot insert duplicate key row in object 'kpi_element_types' with unique index 'IX_element_types_ElementTypeExecutionSequence'. (severity 14) in C:\WebSites\PHP\Includes\class_FormMaint.inc on line 239 The important bit is [function.--destruct.html] which points to url ... http://dev.kpi.bandvulc/phpmanual/function.--destruct.html which doesn't exist. Reproduce code: --- Generating the error was VERY hard work (i.e. 1 line in the wrong place), but is not relevant to the problem. The problem is that there is no documentation for function.--desctruct.html -- Edit this bug report at http://bugs.php.net/?id=30115&edit=1
#29141 [Opn]: configure help has 5 times libxml line
ID: 29141 Updated by: [EMAIL PROTECTED] Reported By: dick at terena dot nl Status: Open -Bug Type: Documentation problem +Bug Type: Unknown/Other Function Operating System: Debian/GNU Linux PHP Version: 5.0.0 New Comment: This is not a documentation problem. Previous Comments: [2004-07-14 11:44:52] dick at terena dot nl Description: The configure help has 5 times explantion of --with-libxml-dir: ./configure --help | grep with-libxml-dir --with-libxml-dir[=DIR] libxml2 install prefix. --with-libxml-dir[=DIR] DOM: libxml2 install prefix. --with-libxml-dir=DIR SimpleXML: libxml2 install prefix --with-libxml-dir=DIR XML: libxml2 install prefix --with-libxml-dir=DIR XML: libxml2 install prefix This looks confusing and redundant. -- Edit this bug report at http://bugs.php.net/?id=29141&edit=1
#26005 [Opn]: Random "cannot change the session's ini settings" errors
ID: 26005 Updated by: [EMAIL PROTECTED] Reported By: parsnip11 at hotmail dot com Status: Open Bug Type: Session related Operating System: * PHP Version: 4CVS-2003-10-31 New Comment: We have tackled down the problem to memory allocation issues. If PHP is unable to allocate more memory it quits, but then the session module still tries to save stuff, and due to the unavailability of memory, it is unable to do so. The interesting part is that regardless of our display_errors=off setting, this session error still gets printed out to the browser (the mem allocation problem is only present in our logs). The session module should not print errors if display_errors is off. Previous Comments: [2004-07-04 13:51:38] [EMAIL PROTECTED] We also experience the same error with PHP 4.3.7 with Apache 1.3.31. We have the following session settings in .htaccess: php_value session.cache_expire20 php_value session.gc_maxlifetime 20 php_value session.cookie_domain ".weblabor.hu" php_value session.cookie_lifetime 200 php_value session.auto_start 0 php_value session.save_handleruser php_value session.cache_limiter none Our session handlers store data in a database, and are set with session_set_save_handler() in userland code. The error is the exact one reported by the bug opener. [2004-07-04 13:25:56] a-n-d-r-a-s at b-a-r-t-h-a-z-i dot hu I have PHP 4.3.7, and we get this error, running a Drupal 4.4. [2004-02-25 13:49:27] [EMAIL PROTECTED] Get the latest stable CVS snapshot. And don't reopen closed bugs unless you can still reproduce it with the snapshot.. [2004-02-25 13:28:20] parsnip11 at hotmail dot com Is there any way that I can apply this patch to php4isapi.dll? [2004-02-24 03:42:35] [EMAIL PROTECTED] Patch applied. Thanks! 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/26005 -- Edit this bug report at http://bugs.php.net/?id=26005&edit=1
#26005 [Csd->Opn]: Random "cannot change the session's ini settings" errors
ID: 26005
Updated by: [EMAIL PROTECTED]
Reported By: parsnip11 at hotmail dot com
-Status: Closed
+Status: Open
Bug Type: Session related
Operating System: *
PHP Version: 4CVS-2003-10-31
New Comment:
We also experience the same error with PHP 4.3.7 with Apache 1.3.31. We
have the following session settings in .htaccess:
php_value session.cache_expire20
php_value session.gc_maxlifetime 20
php_value session.cookie_domain ".weblabor.hu"
php_value session.cookie_lifetime 200
php_value session.auto_start 0
php_value session.save_handleruser
php_value session.cache_limiter none
Our session handlers store data in a database, and are set with
session_set_save_handler() in userland code. The error is the exact one
reported by the bug opener.
Previous Comments:
[2004-07-04 13:25:56] a-n-d-r-a-s at b-a-r-t-h-a-z-i dot hu
I have PHP 4.3.7, and we get this error, running a Drupal 4.4.
[2004-02-25 13:49:27] [EMAIL PROTECTED]
Get the latest stable CVS snapshot. And don't reopen closed bugs unless
you can still reproduce it with the snapshot..
[2004-02-25 13:28:20] parsnip11 at hotmail dot com
Is there any way that I can apply this patch to php4isapi.dll?
[2004-02-24 03:42:35] [EMAIL PROTECTED]
Patch applied. Thanks!
[2004-02-23 07:11:43] jsnajdr at kerio dot com
This is a patch that stopped crashing for me:
*** php-4.3.4/ext/session/session.c Wed Oct 8 12:25:39 2003
--- php-4.3.4-n/ext/session/session.c Tue Dec 9 11:36:24 2003
***
*** 1543,1548
--- 1543,1556
}
}
+ static void php_session_init_globals(php_ps_globals *ps_globals
TSRMLS_DC)
+ {
+ ps_globals->id = NULL;
+ ps_globals->session_status = php_session_none;
+ ps_globals->mod_data = NULL;
+ ps_globals->http_session_vars = NULL;
+ }
+
static void php_rinit_session_globals(TSRMLS_D)
{
PS(id) = NULL;
***
*** 1618,1624
#ifdef ZTS
php_ps_globals *ps_globals;
! ts_allocate_id(&ps_globals_id, sizeof(php_ps_globals), NULL, NULL);
ps_globals = ts_resource(ps_globals_id);
#endif
--- 1626,1632
#ifdef ZTS
php_ps_globals *ps_globals;
! ts_allocate_id(&ps_globals_id, sizeof(php_ps_globals),
(ts_allocate_ctor) php_session_init_globals, NULL);
ps_globals = ts_resource(ps_globals_id);
#endif
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/26005
--
Edit this bug report at http://bugs.php.net/?id=26005&edit=1
#28730 [Opn]: WEB PAGE Missing
ID: 28730 Updated by: [EMAIL PROTECTED] Reported By: mfloryan at bigfoot dot com Status: Open -Bug Type:Website problem +Bug Type:*Compile Issues PHP Version: 4.3.7 New Comment: It is actually http://www.php.net/manual/en/security.globals.php. It should be fixed in the PHP source. Previous Comments: [2004-06-10 16:31:35] mfloryan at bigfoot dot com Description: The page: http://www.php.net/manual/en/security.registerglobals.php is mentioned in the information window after I build PHP, but does not exist. Reproduce code: --- ./configure -- Edit this bug report at http://bugs.php.net/?id=28730&edit=1
#24839 [Csd->Opn]: faulty phpcredits() HTML output
ID: 24839 Updated by: [EMAIL PROTECTED] Reported By: gabor at hojtsy dot hu -Status: Closed +Status: Open Bug Type: Unknown/Other Function Operating System: irrelevant PHP Version: 4.3.3RC1 New Comment: One more bug here (just reopened the bug, not opened a new one, hope it is appropriate): php_info_print_table_header(1, "Language Design & Concept"); should be php_info_print_table_header(1, "Language Design & Concept"); instead to be standards compatible... Previous Comments: [2003-07-28 05:45:14] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-07-28 04:23:54] gabor at hojtsy dot hu Description: In the phpcredits() output, there is a [not align="center"!] before the tables and a after them. This is basically not correct. The latter close tag should be . Reproduce code: --- See HTML source of http://www.php.net/credits.php, which greps out the of phpcredits(), and shows the problem (note that php.net runs 4.3.3-dev) -- Edit this bug report at http://bugs.php.net/?id=24839&edit=1
#24672 [Opn]: "parse" is not similar to "parse_ini_file"
ID: 24672 Updated by: [EMAIL PROTECTED] Reported By: s dot pfalz at teles dot de Status: Open -Bug Type: Website problem +Bug Type: Unknown/Other Function -Operating System: PHP Website de*.php.net mirrors +Operating System: irrelevant PHP Version: Irrelevant New Comment: Recategorizing, as this is a bug of the similar_text() function, and not the website Previous Comments: [2003-07-17 04:03:56] [EMAIL PROTECTED] There are functions returned with double underscores, when searching for "parse" or "parse " (without quotes). Namely yaz_ccl_parse and mb_parse_str. The fact that the parse_ini_file function is not found is probably a bug in the similar_text() function, which we use on the website. [2003-07-16 02:51:29] s dot pfalz at teles dot de Description: When using the PHP.net document search function on de3.php.net to search for parse_ini_file() and using the searchstring "parse " (note the trailing space) this function will be found, but not on de.php.net and de2.php.net. Searching for "parse" only does not even return the parse_ini_file function. There seems to be a problem with double underscores in function names and the website search. Reproduce code: --- Try to search for "parse" on any of the de.php.net mirrors and see yourself what is returned ;) Expected result: Expected to get a list of functions containing the word "parse", but not all functions are returned, mainly none of the functions containing double underscores. Actual result: -- As mentioned above, this is always reproduceable with either Mozilla 1.4 or IE 6.0. -- Edit this bug report at http://bugs.php.net/?id=24672&edit=1
#24672 [Opn]: "parse" is not similar to "parse_ini_file"
ID: 24672 Updated by: [EMAIL PROTECTED] -Summary: Search Documentation - Function list does not work correctly Reported By: s dot pfalz at teles dot de Status: Open -Bug Type: Website problem +Bug Type: Unknown/Other Function Operating System: PHP Website de*.php.net mirrors PHP Version: Irrelevant New Comment: There are functions returned with double underscores, when searching for "parse" or "parse " (without quotes). Namely yaz_ccl_parse and mb_parse_str. The fact that the parse_ini_file function is not found is probably a bug in the similar_text() function, which we use on the website. Previous Comments: [2003-07-16 02:51:29] s dot pfalz at teles dot de Description: When using the PHP.net document search function on de3.php.net to search for parse_ini_file() and using the searchstring "parse " (note the trailing space) this function will be found, but not on de.php.net and de2.php.net. Searching for "parse" only does not even return the parse_ini_file function. There seems to be a problem with double underscores in function names and the website search. Reproduce code: --- Try to search for "parse" on any of the de.php.net mirrors and see yourself what is returned ;) Expected result: Expected to get a list of functions containing the word "parse", but not all functions are returned, mainly none of the functions containing double underscores. Actual result: -- As mentioned above, this is always reproduceable with either Mozilla 1.4 or IE 6.0. -- Edit this bug report at http://bugs.php.net/?id=24672&edit=1
#22253 [Bgs->Opn]: method becomes constructor in subclass
ID: 22253
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: Class/Object related
Operating System: win2k
PHP Version: 4.2.3
New Comment:
No, no and no.
Excerpts:
|In PHP 4, a function becomes a constructor,
|when it has the same name as the class it
|is defined in"
In my example, the function printStr is not defined in class printStr,
so it should not become a constructor according to this statament.
Another example at the bottom of the page you mentioned:
|class A
|{
|function A()
|{
|echo "I am the constructor of A.\n";
|}
|
|function B()
|{
|echo "I am a regular function named B in class
|A.\n";
|echo "I am not a constructor in A.\n";
|}
|}
|
|class B extends A
|{
|function C()
|{
|echo "I am a regular function.\n";
|}
|}
|
|// This will call B() as a constructor.
|$b = new B;
|
|In PHP 3, the function B() in class A will suddenly become
|a constructor in class B, although it was never intended to
|be. The rule in PHP 3 is: 'A constructor is a function of
|the same name as the class.'. PHP 3 does not care if the
|function is being defined in class B, or if it has been
|inherited.
|
|This is fixed in PHP 4 by modifying the rule to: 'A
|constructor is a function of the same name as the class
|it is being defined in.'. Thus in PHP 4, the class B
|would have no constructor function of its own and the
|constructor of the base class would have been called,
|printing 'I am the constructor of A.'.
The above example says, that the B() method becomes a constructor in
PHP 3, but *not* in PHP 4, as there is no constructor defined for class
B itself. Therefore it inherits the base classes constructor, which
exists in the manual's example. In my case, there is no constructor in
the base class. Therefore it should not call any method, as the text
suggests.
So this is not a documented behaviour. In fact it is documented, that
it should not work this way in PHP 4, but only in PHP 3...
Previous Comments:
[2003-02-23 01:20:05] [EMAIL PROTECTED]
It's by design and even documented here:
http://www.php.net/manual/en/language.oop.constructor.php
[2003-02-21 17:37:00] andrew at evilwalrus dot com
According to the comments on the OOP manual page, if a constructor is
not located in the base class, the function of the same name will be
located in subsequent classes, and loaded accordingly. Yes, this is by
design, but no, i personally don't like it... correct me if i'm wrong,
please.
~ Andrew Heebner
[2003-02-17 11:38:10] [EMAIL PROTECTED]
In this example, the printStr() method becomes the constructor of the
printStr class, while I think it should not be working this way... I
hope this is not by design ;)
class String
{
function printStr($string)
{
print $string;
}
}
class printStr extends String {}
$ps = new printStr("abc");
--
Edit this bug report at http://bugs.php.net/?id=22253&edit=1
#21209 [Fbk]: mysql_error isn't returning connections problems.
ID: 21209
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: MySQL related
Operating System: Windows
PHP Version: 4CVS-2002-12-26 (dev)
New Comment:
Michael note that the function states that it gives the error of the
last myqsl operation, but the note says on the page:
| Note: If the optional argument is specified the
| given link is used to retrieve the error message.
| If not, the last opened link is used.
So it implies, that if the parameter is not given,
an opened connection is needed... So the documentation
also needs to be changed.
Please do not close this bug before the mysql_error
documentation is fixed.
Previous Comments:
[2003-01-04 05:23:49] [EMAIL PROTECTED]
Are you using the bundled version of MySQL, if not, which version?
I can't reproduce the bug in any of my systems.
Anyway changing this to a MySQL bug, and will see if it is verified.
[2003-01-03 23:54:27] [EMAIL PROTECTED]
The manual states that mysql_error() without arguments retrieves the
error text of the last recently used MySQL function - _not_ the last
opened connection.
And that's exactly what happens at least here on Linux (tested with
4.3.0 and 4.4.0-CVS as of today).
So if the example doesn't work on Windows, it is broken on Windows. Can
you try the example on its own, without your custom error handler?
[2003-01-03 20:37:16] [EMAIL PROTECTED]
That is not true.
Your code just produces a ``Could not connect: ''
here.
PHP Version 4.4.0-dev
System Windows NT localhost 5.1 build 2600
Build Date Dec 26 2002 20:10:08
Server API Apache
[2003-01-03 17:25:23] [EMAIL PROTECTED]
Actually with
It returns:
Could not connect: Access denied for user: 'mysql_user@localhost'
(Using password: YES)
so using mysql_error() here is just fine, it also manages the
connections' error.
Thank you for your report.
[2002-12-26 18:51:17] [EMAIL PROTECTED]
Hi!
There is an error in the code examples for mysql_fetch_assoc and
_array:
(for mysql_fetch_assoc, at the page for _array is the same error)
[code]
$conn = mysql_connect("localhost", "mysql_user",
"mysql_password");
if (!$conn) {
echo "Unable to connect to DB: " . mysql_error();
exit;
}
[/code]
That doesn't make sense. mysql_error() takes the connection that is
passed as an argument or the last opened connection. Where
mysql_error() is called, no connection to a mysql server is
established, so mysql_error() returns an empty string. Additionaly PHP
raises an E_WARNING error anyway in case mysql_connect fails. Sample
Output: (custom error handler)
[output]
Warning:
mysql_connect() [function.mysql-connect]: Access denied for user:
'mysql_user@localhost' (Using password: YES)
On Line: 2
In File: c:\web\apache\htdocs\test.php
Error Context: $conn = mysql_connect("localhost", "mysql_user",
"mysql_password");
Unable to connect to DB:
[/output]
Suggestion:
a) Change the examples so that they catch the errors in a way that is
appropriate, i.e.:
[code]
$conn = @mysql_connect("localhost", "mysql_user", "mysql_password");
if (empty($conn)) {
echo "Unable to connect to DB: " . $GLOBALS['php_errormsg'];
exit;
}
[/code]
b) More work, but would be nicer and match the documentation for
mysql_error - yet this changes the behaviour a lot, some scripts would
have to be rewritten:
Let mysql_connect no longer issue warnings ("Errors coming back from
the MySQL database backend no longer issue warnings. Instead, use
mysql_error() to retrieve the error text." - Manual page for
mysql_error() ), but modify mysql_error so that it holds error strings
from mysql_connect as well.
--
Edit this bug report at http://bugs.php.net/?id=21209&edit=1
#21053 [Opn]: ftp_exec() return value modification
ID: 21053
Updated by: [EMAIL PROTECTED]
-Summary: ftp_exec() operation doesn't match documentation
Reported By: [EMAIL PROTECTED]
Status: Open
-Bug Type: Documentation problem
+Bug Type: FTP related
Operating System: FreeBSD 4.6.2
PHP Version: 4.2.3
New Comment:
What you sent in your report is not a documentation problem, but an FTP
related feature request. Because you includeded C source code too, I
recategorize this as FTP related. Also modified summary
Previous Comments:
[2002-12-16 15:24:20] [EMAIL PROTECTED]
The ftp_exec routine in PHP 4.2.3 doesn't work as advertised in the
manual, returning true or false status rather than command output.
I've written a replacement version of the routine, which has worked
well for me under FreeBSD 4.6.2. My changes were:
in ftp.h:
/* exec a command [special features], return response on success, false
on error */
char** ftp_exec(ftpbuf_t *ftp, const char *cmd);
(change return type from int to char**)
in php_ftp.c:
/* {{{ proto array ftp_exec(resource stream, string cmd)
Returns the results of a system command as an array of output lines
*/
PHP_FUNCTION(ftp_exec)
{
pval*z_ftp;
ftpbuf_t*ftp;
char**llist, **ptr, *cmd;
int cmd_len;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rs", &z_ftp,
&cmd, &cmd_len) == FAILURE) {
return;
}
ZEND_FETCH_RESOURCE(ftp, ftpbuf_t*, &z_ftp, -1, le_ftpbuf_name,
le_ftpbuf);
/* get raw command output */
if (NULL == (llist = ftp_exec(ftp, cmd))) {
RETURN_FALSE;
}
array_init(return_value);
for (ptr = llist; *ptr; ptr++)
add_next_index_string(return_value, *ptr, 1);
free(llist);
}
/* }}} */
Finally, in ftp.c:
/* {{{ ftp_exec
*/
char**
ftp_exec(ftpbuf_t *ftp, const char *cmd)
{
char**ret = NULL;
char**entry;
char*text;
if (!ftp_type(ftp, FTPTYPE_ASCII))
return NULL;
if (!ftp_putcmd(ftp, "SITE EXEC", cmd))
return NULL;
ret = malloc(FTP_BUFSIZE * sizeof(char*));
if (ret == NULL) {
perror("malloc");
return NULL;
}
entry = ret;
text = (char*) (ret + 100);
*entry = text;
while(1) {
if (!ftp_readline(ftp)) {
free(ret);
return NULL;
}
strcpy(text, ftp->inbuf);
text += strlen(ftp->inbuf) + 1;
*++entry = text;
/* Break out when the end-tag is found */
if (isdigit(ftp->inbuf[0]) &&
isdigit(ftp->inbuf[1]) &&
isdigit(ftp->inbuf[2]) &&
ftp->inbuf[3] == ' ') {
break;
}
}
*entry = NULL;
return ret;
}
/* }}} */
I had to make, make install, etc, then restart the httpd to pick up the
new version.
The code works for me, returning an array of the raw output of a
command, one line per array entry. We needed the output from "site
exec quota -v", which from our mailserver comes prefixed with
intermediate status levels:
200-quota -v
200-Disk quotas for jqpublic (uid 12345):
200-Filesystem usage quota limittimeleft ...
...
200 (end of 'quota -v')
It requires some extra parsing at the application end, but I figured
it's safer to have to parse, than to have to figure out all the
possible styles of output ahead of time.
PDM
--
Edit this bug report at http://bugs.php.net/?id=21053&edit=1
#20574 [Opn]: Cannot report bug
ID: 20574 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Website problem +Bug Type: Feature/Change Request Operating System: n/a PHP Version: 4.3.0RC1 New Comment: Change request [for the bug system], but this is not a website problem itself, the devteam should consider it... Previous Comments: [2002-11-22 10:28:39] [EMAIL PROTECTED] The web site will not allow me to report a bug in an older version of PHP. However, the version in question is still in common use and is shipped as part of RedHat 7.1, which is a very commonly used distribution. Upgrading an application server on a live site is a a step which should not be taken litely, and one which I am probably not going to do just so that I can verify for you whether or not this bug (which has not been previously reported) is already fixed. Also, despite the fact that I am not currently reporting a bug in PHP, this web site requires me to select a version of PHP to report a bug in... -- Edit this bug report at http://bugs.php.net/?id=20574&edit=1
#19989 [Opn]: snaps.php.net LDAP extension build failure.
ID: 19989 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Website problem +Bug Type: LDAP related Operating System: Windows PHP Version: 4CVS-2002-10-19 New Comment: This is an LDAP related bug IMHO. Recategorizing. Previous Comments: [2002-10-19 08:55:38] [EMAIL PROTECTED] The LDAP extension has not compiled successfully for a few days now on snaps.php.net Just so you know :-) - Mike :-) Configuration: ldap - Win32 Release_TS Compiling... ldap.c Linking... Creating library Release_TS/php_ldap.lib and object Release_TS/php_ldap.exp oldap32.lib(getdn.obj) : error LNK2001: unresolved external symbol _OBJ_obj2txt oldap32.lib(getdn.obj) : error LNK2001: unresolved external symbol _OBJ_nid2sn oldap32.lib(getdn.obj) : error LNK2001: unresolved external symbol _OBJ_obj2nid oldap32.lib(getdn.obj) : error LNK2001: unresolved external symbol _X509_NAME_ENTRY_get_data oldap32.lib(getdn.obj) : error LNK2001: unresolved external symbol _X509_NAME_ENTRY_get_object oldap32.lib(getdn.obj) : error LNK2001: unresolved external symbol _X509_NAME_get_entry oldap32.lib(getdn.obj) : error LNK2001: unresolved external symbol _X509_NAME_entry_count oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _ERR_free_strings oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _EVP_cleanup oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_CTX_free oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _X509V3_add_standard_extensions oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_library_init oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_load_error_strings oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_CTX_set_tmp_rsa_callback oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_CTX_set_verify oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_CTX_check_private_key oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_CTX_use_certificate_file oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_CTX_use_PrivateKey_file oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_CTX_set_client_CA_list oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_CTX_set_default_verify_paths oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_CTX_load_verify_locations oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_CTX_set_cipher_list oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_CTX_set_session_id_context oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _ERR_peek_error oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_CTX_new oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSLv23_method oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _sk_new_null oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_load_client_CA_file oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_set_bio oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _BIO_new oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_free oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_shutdown oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_pending oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_get_error oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_read oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_write oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_accept oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_new oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_CIPHER_get_bits oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_get_current_cipher oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _X509_get_subject_name oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_get_certificate oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _X509_free oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_get_peer_certificate oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _SSL_get_verify_result oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _X509_NAME_get_text_by_NID oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _GENERAL_NAMES_free oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _ASN1_STRING_length oldap32.lib(tls.obj) : error LNK2001: unresolved external symbol _ASN1_STRING_data old
#19654 [NEW]: function to call class methods
From: [EMAIL PROTECTED] Operating system: n/a PHP version: 4.2.3 PHP Bug Type: Feature/Change Request Bug description: function to call class methods We have $$objname->$methodname() for dinamic method calls, and even call_user_func(array(&$$objname, $methodname), but we have no $classname::$methodname() or call_class_method($classname, $methodname) or anything like this. It would be nice to call class methods dinamicaly, as many times classes are used for namespace resons, and there is no need to have instances of them. -- Edit bug report at http://bugs.php.net/?id=19654&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19654&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19654&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19654&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19654&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19654&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19654&r=support Expected behavior: http://bugs.php.net/fix.php?id=19654&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19654&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19654&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19654&r=globals
#19560 [Opn->Bgs]: About the manual
ID: 19560 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: none PHP Version: 4.2.3 New Comment: Please read what's written on the documentation downloads page. Previous Comments: [2002-09-23 12:35:30] [EMAIL PROTECTED] The PDF has corrupted links. In page 8, What references are, points to page ??. Besides I tried to locate some functions related to mysql, but there nothing in the file. Thanks -- Edit this bug report at http://bugs.php.net/?id=19560&edit=1
#19464 [Opn->Asn]: "Oracle Collections" functions (ocicol*) in manual are not documented for ages.
ID: 19464 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: Documentation problem Operating System: n/a PHP Version: 4.2.3 -Assigned To: +Assigned To: thies New Comment: Assigned to Thies, the extension maintainer. Previous Comments: [2002-09-18 01:53:32] [EMAIL PROTECTED] "Oracle Collections" functions (ocicol*) in manual are not documented for ages. At lest for a year as I can remember. -- Edit this bug report at http://bugs.php.net/?id=19464&edit=1
#19472 [Opn->Asn]: Spanish CHM manual won't open
ID: 19472 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: Documentation problem Operating System: Windows XP PHP Version: 4.2.3 -Assigned To: +Assigned To: derick New Comment: Assigned to Derick. Previous Comments: [2002-09-18 05:35:46] [EMAIL PROTECTED] CHM version of the Spanish PHP manual from the Download section (size 1736 Kb, date 15 sep 2002) cannot be opened. Apparently this only happens with the Spanish. I tried to open the Italian and the English CHM files and both of them work. Error message: "Can't open file: mk:@MSITStore:C:\php_manual_es.chm" -- Edit this bug report at http://bugs.php.net/?id=19472&edit=1
#19465 [Opn->Fbk]: httpd.conf Fix for Apache 2
ID: 19465 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: Windows 2000 PHP Version: 4.2.3 New Comment: Actually the documentation on installation has more information on the AddModule directive, and when to use it. Please recheck that that documentation is ok or not, and provide feedback. Thanks. Previous Comments: [2002-09-18 03:32:46] [EMAIL PROTECTED] For an Apache installation : The install.txt suggests to add 3 lines to httpd.conf LoadModule php4_module c:/php/sapi/php4apache.dll AddModule mod_php4.c AddType application/x-httpd-php .php However AddModule mod_php4.c caused errors on my installation Windows2000/Apache2. Putting this line in comment (or not adding it) worked. I found this solution in the newsgroups. -- Edit this bug report at http://bugs.php.net/?id=19465&edit=1
#19462 [Opn->Asn]: Page in Dutch in the English manual
ID: 19462 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: Documentation problem Operating System: Windows PHP Version: 4.2.1 -Assigned To: +Assigned To: derick New Comment: Assigning this to Derick Previous Comments: [2002-09-17 23:45:27] [EMAIL PROTECTED] In the PHM English language .chm format documentation (version: This file was generated: Sun Sep 08 02:07:01 2002) there is a page in Dutch called: "Meerdere bestanden uploaden" (Hoofdstuk 20. Bestanden uploaden naar server). I came across it when searching for the word "submit". -- Edit this bug report at http://bugs.php.net/?id=19462&edit=1
#19453 [Opn->Asn]: [chm] bug on function.error-reporting.html
ID: 19453 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: Documentation problem Operating System: windows PHP Version: 4.2.3 -Assigned To: +Assigned To: goba New Comment: We are working on a solution for it. Previous Comments: [2002-09-17 08:44:33] [EMAIL PROTECTED] I have found a bug on page function.error-reporting.html [chm date: 2002-08-28]... new manual wont copy .. copy to clipboard is not working -- Edit this bug report at http://bugs.php.net/?id=19453&edit=1
Bug #17435 Updated: unset() of the globalized variable
ID: 17435
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Documentation problem
Operating System: Linux/Windows
PHP Version: 4.2.0
New Comment:
Please read the manual carefully. You have never used
unset($input), which would be the case described by
that sentence you have quoted. You've never unset the
globalized variable, so that sentence is in no
relation to your code. There's no need to correct the
documentation, it's already correct.
Previous Comments:
[2002-05-27 12:02:36] [EMAIL PROTECTED]
Sure.
My script works with sockets and there is a function that closes the
socket and destroys all the variables connected to it. $output and
$input are arrays of sockets. Here is the code:
function socket_kill_my_socket($i) {
global $fset, $output, $input;
$fnd = array_search($i, $fset);
unset($fset[$fnd]);
unset($output[$i]);
unset($input[$i]);
socket_shutdown($i); //???
socket_close($i);
echo "Closed $i";
}
[2002-05-26 15:04:26] [EMAIL PROTECTED]
Can you please provide us with a code where we
can reproduce what you've said?
[2002-05-26 13:34:55] [EMAIL PROTECTED]
Are you completely sure? But why are the globalized variables destroyed
in my scripts?
Ps. Another bug is handling ' and \ in Bug Report system :)
[2002-05-26 13:23:20] [EMAIL PROTECTED]
Sorry, but the bug system is not the appropriate forum for asking
support questions. Your problem does not imply a bug in PHP itself.
For a list of more appropriate places to ask for help using PHP,
please visit http://www.php.net/support.php
Thank you for your interest in PHP.
unset()\'s documentation is perfectly right on this point.
[2002-05-26 13:21:42] [EMAIL PROTECTED]
The article about unset() says: "If a globalized variable is unset()
inside of a function, only the local variable is destroyed. The
variable in the calling environment will retain the same value as
before unset() was called." It is != true!
--
Edit this bug report at http://bugs.php.net/?id=17435&edit=1
Bug #17435 Updated: unset() of the globalized variable
ID: 17435 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Documentation problem Operating System: Linux/Windows PHP Version: 4.2.0 New Comment: Can you please provide us with a code where we can reproduce what you've said? Previous Comments: [2002-05-26 13:34:55] [EMAIL PROTECTED] Are you completely sure? But why are the globalized variables destroyed in my scripts? Ps. Another bug is handling ' and \ in Bug Report system :) [2002-05-26 13:23:20] [EMAIL PROTECTED] Sorry, but the bug system is not the appropriate forum for asking support questions. Your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Thank you for your interest in PHP. unset()\'s documentation is perfectly right on this point. [2002-05-26 13:21:42] [EMAIL PROTECTED] The article about unset() says: "If a globalized variable is unset() inside of a function, only the local variable is destroyed. The variable in the calling environment will retain the same value as before unset() was called." It is != true! -- Edit this bug report at http://bugs.php.net/?id=17435&edit=1
Bug #16792 Updated: [chm] bug on features.http-auth.html
ID: 16792 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Documentation problem Operating System: windows PHP Version: 4.1.2 New Comment: BTW expect the fix to come in the next sample... Goba Previous Comments: [2002-05-22 07:22:06] [EMAIL PROTECTED] It's intended only to test it out, for quick download and test, so the size [and content] is limited. Thanks for your feedback. I am happy to hear, that all works well... Goba [2002-05-22 02:54:18] [EMAIL PROTECTED] This documentation is not complete, but I guess it's intended only for testing. But what about function - work fine. I tested all items and categories and problems didn't appear again. [2002-05-21 13:12:03] [EMAIL PROTECTED] This bug can be closed after feedback about the version from http://weblabor.hu/php-doc-chm/manual_notes_test.zip tom [2002-05-20 15:33:02] [EMAIL PROTECTED] Can you please test this with http://weblabor.hu/php-doc-chm/manual_notes_test.zip Thank you Goba [2002-04-24 14:01:47] [EMAIL PROTECTED] What OS do you exactly use? What IE do you have installed. Aren't there errors on other pages? This error should pop up on all pages all the time, or nowhere, or on all pages sometimes, depending on what is the real error ;) (Note for phpdoc bug readers: this is the form of bug reports from the new chms. I hope it is good enough. I have included automations to post page names and CHM dates for guys to be able to trace if this error is corrected since that CHM release or not.) 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/16792 -- Edit this bug report at http://bugs.php.net/?id=16792&edit=1
Bug #16792 Updated: [chm] bug on features.http-auth.html
ID: 16792 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Documentation problem Operating System: windows PHP Version: 4.1.2 New Comment: It's intended only to test it out, for quick download and test, so the size [and content] is limited. Thanks for your feedback. I am happy to hear, that all works well... Goba Previous Comments: [2002-05-22 02:54:18] [EMAIL PROTECTED] This documentation is not complete, but I guess it's intended only for testing. But what about function - work fine. I tested all items and categories and problems didn't appear again. [2002-05-21 13:12:03] [EMAIL PROTECTED] This bug can be closed after feedback about the version from http://weblabor.hu/php-doc-chm/manual_notes_test.zip tom [2002-05-20 15:33:02] [EMAIL PROTECTED] Can you please test this with http://weblabor.hu/php-doc-chm/manual_notes_test.zip Thank you Goba [2002-04-24 14:01:47] [EMAIL PROTECTED] What OS do you exactly use? What IE do you have installed. Aren't there errors on other pages? This error should pop up on all pages all the time, or nowhere, or on all pages sometimes, depending on what is the real error ;) (Note for phpdoc bug readers: this is the form of bug reports from the new chms. I hope it is good enough. I have included automations to post page names and CHM dates for guys to be able to trace if this error is corrected since that CHM release or not.) [2002-04-24 09:14:07] [EMAIL PROTECTED] I have found a bug on page features.http-auth.html [chm date: 2002-04-20]... I found at least 2 bugs with the same message reported: 'document.all.unotes' is null or not an object Reported on openning following items: "HTTP authentication with PHP" and "Function reference" items on line 3, char 25. Manual php_manual_en.chm distributed in php_manual_sample_5.zip -- Edit this bug report at http://bugs.php.net/?id=16792&edit=1
Bug #16398 Updated: Eng. chm: "Predefined constants" is missing
ID: 16398 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Documentation problem Operating System: Win2k PHP Version: 4.1.2 Previous Comments: [2002-05-10 15:55:31] [EMAIL PROTECTED] Can you try with the latest CHM? Derick [2002-04-02 16:45:50] [EMAIL PROTECTED] The eng. chm (30 Mar 2002) has the "Predefined constants" page, under Appendix H, that is missing. Regards, Nicola -- Edit this bug report at http://bugs.php.net/?id=16398&edit=1
Bug #17132 Updated: [chm] bug on function.header.html
ID: 17132 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Documentation problem Operating System: windows PHP Version: 4.0CVS-2002-05-09 New Comment: Can you please test this with http://weblabor.hu/php-doc-chm/manual_notes_test.zip Please provide feedback then. Thanks Goba Previous Comments: [2002-05-16 14:42:24] [EMAIL PROTECTED] There is a new version available (built 2002-05-09), in which I can't find an error at the "header" function. (Don't have the old version to check it). Would you please check this new version if the problem still persisits? [2002-05-10 04:38:27] [EMAIL PROTECTED] Reclassified. [2002-05-09 23:50:06] [EMAIL PROTECTED] I have found a bug on page function.header.html [chm date: 2002-04-20]... 'document.all.unotes' is null or not an object -- Edit this bug report at http://bugs.php.net/?id=17132&edit=1
Bug #17028 Updated: [chm] bug on language.types.resource.html
ID: 17028 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Documentation problem Operating System: windows PHP Version: 4.1.2 New Comment: For the unotes bugs, please check out http://weblabor.hu/php-doc-chm/manual_notes_test.zip There is a small test version with a new method of getting in the notes, so this error should not pop up anymore. Please provide feedback. Goba Previous Comments: [2002-05-20 15:54:47] [EMAIL PROTECTED] Hi, there seems to be a misunderstanding. While Goba asked about the software, I've meant the new version of the manual at http://www.php.net/download-docs.php (curr. build 2002-05-20). Thomas [2002-05-17 20:26:00] [EMAIL PROTECTED] Now I can't do the "Edit Submission" on the actual bug, it states that I "can't change bug to that state"...Did I miss something? Anyway thanks...where is this newer version? All I see is the version 5, built March 20th. Dennis Williams [2002-05-16 14:51:10] [EMAIL PROTECTED] There is a new version available (built 2002-05-09), in which I don't get such an error. (Don't have the old version to check it). Would you please check this new version if the problem still persisits? Thomas [2002-05-06 09:23:01] [EMAIL PROTECTED] WinME (4.90.3000) + IE 5.5 (128-bit Cipher Strength) Thanks, Dennis Williams [2002-05-06 04:07:55] [EMAIL PROTECTED] Strange. I still cannot reproduce any of these bugs with IE6 + Winxp and IE5 + Win2k. What Win OS do you have? Goba 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/17028 -- Edit this bug report at http://bugs.php.net/?id=17028&edit=1
Bug #16856 Updated: [chm] bugs
ID: 16856 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: windows PHP Version: 4.2.0 New Comment: Caan you please test this with http://weblabor.hu/php-doc-chm/manual_notes_test.zip Thanks Goba Previous Comments: [2002-04-26 13:47:28] [EMAIL PROTECTED] Once again, I cannot reproduce any of these bugs. I have already checked now this CHM set on a freshly installed XP with IE6 security update, but otherwise default IE settings, and all seems OK, including user notes, high design. I have experienced *no* errors. Can you find any usual on those pages you experience these errors? Are these very long pages? Are these short ones? Do they have any special character in their names, or any other similarities? [2002-04-26 13:42:30] [EMAIL PROTECTED] Hey, you said: "High theme shows lots of JS errors" and now you are speaking about the low theme [general] errors. I asked about the high skin errors. It was not that obvious though... The notes autofind code is thought to be safe enough to fall back if there is no file. [2002-04-26 13:20:08] [EMAIL PROTECTED] About 'page not found' errors. It seems to me that it isn't a random occuring bug - this error shows on same pages all over the time. Also, when 'page not found' - it shows a location *inside manual_notes.chm* file, not the main file. As it seems to me, pages like /introduction.html are supposed to be inside php_manual_LANG.chm? Hope that helps. [2002-04-26 13:13:33] [EMAIL PROTECTED] When first opening manual, at page "Getting Started", for example, it pops JS error 'document.all.unotes is null or not an object'. Theme - light one. IE 6.0.2600 on Win XP. [2002-04-26 12:10:09] [EMAIL PROTECTED] We are working on the first point. It will be corrected as soon as a) we found the exact problem b) found the solution for that c) and have enough time to do this all ;) For the second bug, there no more JS for the high skin, then the low skin, they only differ in CSS code significantly. What kind of JS errors you get? What exact errors do you get (error messages - *not* full debug info please)? 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/16856 -- Edit this bug report at http://bugs.php.net/?id=16856&edit=1
Bug #16792 Updated: [chm] bug on features.http-auth.html
ID: 16792 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: windows PHP Version: 4.1.2 New Comment: Can you please test this with http://weblabor.hu/php-doc-chm/manual_notes_test.zip Thank you Goba Previous Comments: [2002-04-24 14:01:47] [EMAIL PROTECTED] What OS do you exactly use? What IE do you have installed. Aren't there errors on other pages? This error should pop up on all pages all the time, or nowhere, or on all pages sometimes, depending on what is the real error ;) (Note for phpdoc bug readers: this is the form of bug reports from the new chms. I hope it is good enough. I have included automations to post page names and CHM dates for guys to be able to trace if this error is corrected since that CHM release or not.) [2002-04-24 09:14:07] [EMAIL PROTECTED] I have found a bug on page features.http-auth.html [chm date: 2002-04-20]... I found at least 2 bugs with the same message reported: 'document.all.unotes' is null or not an object Reported on openning following items: "HTTP authentication with PHP" and "Function reference" items on line 3, char 25. Manual php_manual_en.chm distributed in php_manual_sample_5.zip -- Edit this bug report at http://bugs.php.net/?id=16792&edit=1
Bug #17276 Updated: example in CLI docs uses CGI command line option
ID: 17276 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: - PHP Version: 4.2.1 New Comment: OK, I had the time and facilities to correct this bug. I hope it will be OK now. It will show up in some days in the manual. Previous Comments: [2002-05-16 15:46:48] [EMAIL PROTECTED] This *is* a bug. The CLI version, command line options, etc. is explained in the text but the example uses the CGI version. Reopening. [2002-05-16 15:39:35] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2002-05-16 15:37:22] [EMAIL PROTECTED] The page at /manual/en/features.commandline.php uses a CGI-only option in the last example: Example 24-2. Batch file to run a command line PHP script (script.bat) @c:\php\php.exe -q script.php %1 %2 %3 %4 -- Edit this bug report at http://bugs.php.net/?id=17276&edit=1
Bug #17276 Updated: example in CLI docs uses CGI command line option
ID: 17276 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Documentation problem Operating System: - PHP Version: 4.2.1 New Comment: This *is* a bug. The CLI version, command line options, etc. is explained in the text but the example uses the CGI version. Reopening. Previous Comments: [2002-05-16 15:39:35] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2002-05-16 15:37:22] [EMAIL PROTECTED] The page at /manual/en/features.commandline.php uses a CGI-only option in the last example: Example 24-2. Batch file to run a command line PHP script (script.bat) @c:\php\php.exe -q script.php %1 %2 %3 %4 -- Edit this bug report at http://bugs.php.net/?id=17276&edit=1
Bug #17217 Updated: javascript errors on some pages of the chm versionof manual
ID: 17217 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Duplicate Bug Type: Documentation problem Operating System: windows 2000 PHP Version: 4.2.0 Previous Comments: [2002-05-14 16:45:34] [EMAIL PROTECTED] Thanks, we are already aware of this problem. I do not know exactly what the *cause* of the error is, but I'll try to make some generalisations, and maybe this will also be fixed in the next release. [2002-05-14 16:42:55] [EMAIL PROTECTED] javascript errors on pages of the chm version 4+5, ie6 is installed. ie 'document.all.unotes' is null or not an object. -- Edit this bug report at http://bugs.php.net/?id=17217&edit=1
Bug #17217 Updated: javascript errors on some pages of the chm versionof manual
ID: 17217 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: windows 2000 PHP Version: 4.2.0 New Comment: Thanks, we are already aware of this problem. I do not know exactly what the *cause* of the error is, but I'll try to make some generalisations, and maybe this will also be fixed in the next release. Previous Comments: [2002-05-14 16:42:55] [EMAIL PROTECTED] javascript errors on pages of the chm version 4+5, ie6 is installed. ie 'document.all.unotes' is null or not an object. -- Edit this bug report at http://bugs.php.net/?id=17217&edit=1
Bug #17171 Updated: 'document.all.unotes' is null or not an object
ID: 17171 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Windows 2000 sp2 PHP Version: 4.2.0 New Comment: Please do not submit the same bug more than once. Previous Comments: [2002-05-12 22:45:33] [EMAIL PROTECTED] 'document.all.unotes' is null or not an object line 3 char 25 code 0 url: mk:@MSITStore:C:\Inetpub\PHP\manual\php_manual_en.chm::/ref.image.html happens when i searched for images and open the page above -- Edit this bug report at http://bugs.php.net/?id=17171&edit=1
Bug #17028 Updated: [chm] bug on language.types.resource.html
ID: 17028 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: windows PHP Version: 4.1.2 New Comment: Strange. I still cannot reproduce any of these bugs with IE6 + Winxp and IE5 + Win2k. What Win OS do you have? Goba Previous Comments: [2002-05-06 01:06:31] [EMAIL PROTECTED] I have found a bug on page language.types.resource.html [chm date: 2002-04-20]... I don't know if this is exactly a bug...it seems to do with IE 5.5 and script debugging. (I do have Microsoft Script Debugger installed on my system.) Even though I have script debugging turned off (and continue flag set to true when scripting errors encountered) I still get this pop-up on most pages in the .chm format help file: Internet Explorer Script Error An error has occurred in the script on this page. Line: 3 Char: 25 Error: 'document.all.unotes' is null or not an object Code: 0 URL: ... Do you want to continue running scripts on this page? Yes|No Line number, character number and error message seem to remain constant on all pages where this occurs. Thanks, Dennis Williams -- Edit this bug report at http://bugs.php.net/?id=17028&edit=1
Bug #17010 Updated: not clearly documented import_request_variables
ID: 17010 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: n/a PHP Version: 4.2.0 New Comment: I hope I clearead this thing now ;) Previous Comments: [2002-05-05 04:33:09] [EMAIL PROTECTED] The "prefix" argument in import_request_variables is not clearly documented. From a short note one may think (and someone actually did, that's why I'm reporting this) that "prefix" is used to specify which variables to import (starting with prefix...). -- Edit this bug report at http://bugs.php.net/?id=17010&edit=1
Bug #16945: bug in syntax highlight
From: [EMAIL PROTECTED]
Operating system: win2k
PHP version: 4.1.2
PHP Bug Type: Unknown/Other Function
Bug description: bug in syntax highlight
While generating the new CHM highlights I came across a bug. Seems like the
syntax highliter does not like backslashes in strings, or something like
that...
This example was on the preg_match_all() page.
The original source:
preg_match_all ("/(<([\w]+)[^>]*>)(.*)(<\/\\2>)/", $html, $matches);
The output of the highlight:
preg_match_all ("/(<([
Warning: Unexpected character in input: '\' (ASCII=92) state=1 in
E:\phpcvs\phpdoc\htmlhelp\filter_files.php on line 180
w]+)[^>]*>)(.*)(<
Warning: Unexpected character in input: '\' (ASCII=92) state=1 in
E:\phpcvs\phpdoc\htmlhelp\filter_files.php on line 180
/
Warning: Unexpected character in input: '\' (ASCII=92) state=1 in
E:\phpcvs\phpdoc\htmlhelp\filter_files.php on line 180
Warning: Unexpected character in input: '\' (ASCII=92) state=1 in
E:\phpcvs\phpdoc\htmlhelp\filter_files.php on line 180
2>)/", $html, $matches);
--
Edit bug report at http://bugs.php.net/?id=16945&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16945&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16945&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16945&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16945&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16945&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16945&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16945&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16945&r=submittedtwice
Bug #16930 Updated: Add line to install.txt
ID: 16930 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Documentation problem Operating System: windows + apache PHP Version: 4.2.0 New Comment: Thomas, you are mixing two kind of setups, the module version, and the CGI version. You'd better read the documentation wit more attention. Goba Previous Comments: [2002-04-30 17:31:07] [EMAIL PROTECTED] This is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2002-04-30 11:35:04] [EMAIL PROTECTED] install.txt of php4.2.0-win32 says on installing php with apache on windows: Then you should add the following three lines to your Apache conf file: (swap c:/php/ for your PHP install path) LoadModule php4_module c:/php/sapi/php4apache.dll AddModule mod_php4.c AddType application/x-httpd-php .php To get it working I had to add theses lines, too: ScriptAlias/php4/"C:/php/" Action application/x-httpd-php/php4/sapi/php.exe I use: apache_1.3.24-win32-x86-no_src.msi Thank you for developing this software! thomas -- Edit this bug report at http://bugs.php.net/?id=16930&edit=1
Bug #16882 Updated: HTML Help crashes opening php_manual_en.chm
ID: 16882 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Win XP PHP Version: 4.2.0 New Comment: What HTML Help is it actually. From php.net or from weblabor.hu? Previous Comments: [2002-04-27 21:13:23] [EMAIL PROTECTED] HTML Help (latest version) crashes when opening php_manual_en.chm under Windows XP Pro. hh.exe opens other documents (not from php document page) correctly. AppName: hh.exe AppVer: 4.74.9273.0 ModName: itss.dll ModVer: 4.72.8085.0 Offset: 252c My preferred editor could open context sensitive help for a keyword (e.g. PHP function) with one keystroke - so I consider properly working HTML help a tremendous help in coding and debugging - compared to the other available formats. -- Edit this bug report at http://bugs.php.net/?id=16882&edit=1
Bug #16856 Updated: [chm] bugs
ID: 16856 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: windows PHP Version: 4.2.0 New Comment: Once again, I cannot reproduce any of these bugs. I have already checked now this CHM set on a freshly installed XP with IE6 security update, but otherwise default IE settings, and all seems OK, including user notes, high design. I have experienced *no* errors. Can you find any usual on those pages you experience these errors? Are these very long pages? Are these short ones? Do they have any special character in their names, or any other similarities? Previous Comments: [2002-04-26 13:42:30] [EMAIL PROTECTED] Hey, you said: "High theme shows lots of JS errors" and now you are speaking about the low theme [general] errors. I asked about the high skin errors. It was not that obvious though... The notes autofind code is thought to be safe enough to fall back if there is no file. [2002-04-26 13:20:08] [EMAIL PROTECTED] About 'page not found' errors. It seems to me that it isn't a random occuring bug - this error shows on same pages all over the time. Also, when 'page not found' - it shows a location *inside manual_notes.chm* file, not the main file. As it seems to me, pages like /introduction.html are supposed to be inside php_manual_LANG.chm? Hope that helps. [2002-04-26 13:13:33] [EMAIL PROTECTED] When first opening manual, at page "Getting Started", for example, it pops JS error 'document.all.unotes is null or not an object'. Theme - light one. IE 6.0.2600 on Win XP. [2002-04-26 12:10:09] [EMAIL PROTECTED] We are working on the first point. It will be corrected as soon as a) we found the exact problem b) found the solution for that c) and have enough time to do this all ;) For the second bug, there no more JS for the high skin, then the low skin, they only differ in CSS code significantly. What kind of JS errors you get? What exact errors do you get (error messages - *not* full debug info please)? [2002-04-26 11:55:09] [EMAIL PROTECTED] [chm date: 2002-04-20] Numerous bugs in New PHP Manual Sample: - lot's of pages show "Page could not be displayed", very annoying, for example, mssql fuctions from Index tab. - High theme shows lots of JS errors -- Edit this bug report at http://bugs.php.net/?id=16856&edit=1
Bug #16856 Updated: [chm] bugs
ID: 16856 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: windows PHP Version: 4.2.0 New Comment: Hey, you said: "High theme shows lots of JS errors" and now you are speaking about the low theme [general] errors. I asked about the high skin errors. It was not that obvious though... The notes autofind code is thought to be safe enough to fall back if there is no file. Previous Comments: [2002-04-26 13:20:08] [EMAIL PROTECTED] About 'page not found' errors. It seems to me that it isn't a random occuring bug - this error shows on same pages all over the time. Also, when 'page not found' - it shows a location *inside manual_notes.chm* file, not the main file. As it seems to me, pages like /introduction.html are supposed to be inside php_manual_LANG.chm? Hope that helps. [2002-04-26 13:13:33] [EMAIL PROTECTED] When first opening manual, at page "Getting Started", for example, it pops JS error 'document.all.unotes is null or not an object'. Theme - light one. IE 6.0.2600 on Win XP. [2002-04-26 12:10:09] [EMAIL PROTECTED] We are working on the first point. It will be corrected as soon as a) we found the exact problem b) found the solution for that c) and have enough time to do this all ;) For the second bug, there no more JS for the high skin, then the low skin, they only differ in CSS code significantly. What kind of JS errors you get? What exact errors do you get (error messages - *not* full debug info please)? [2002-04-26 11:55:09] [EMAIL PROTECTED] [chm date: 2002-04-20] Numerous bugs in New PHP Manual Sample: - lot's of pages show "Page could not be displayed", very annoying, for example, mssql fuctions from Index tab. - High theme shows lots of JS errors -- Edit this bug report at http://bugs.php.net/?id=16856&edit=1
Bug #16856 Updated: [chm] bugs
ID: 16856 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: windows PHP Version: 4.2.0 New Comment: We are working on the first point. It will be corrected as soon as a) we found the exact problem b) found the solution for that c) and have enough time to do this all ;) For the second bug, there no more JS for the high skin, then the low skin, they only differ in CSS code significantly. What kind of JS errors you get? What exact errors do you get (error messages - *not* full debug info please)? Previous Comments: [2002-04-26 11:55:09] [EMAIL PROTECTED] [chm date: 2002-04-20] Numerous bugs in New PHP Manual Sample: - lot's of pages show "Page could not be displayed", very annoying, for example, mssql fuctions from Index tab. - High theme shows lots of JS errors -- Edit this bug report at http://bugs.php.net/?id=16856&edit=1
Bug #16763 Updated: '
ID: 16763 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: ALL PHP Version: 4.2.0 New Comment: Erm, my prev not was not intended to be against this new form, I just intended to add some more info ;) Previous Comments: [2002-04-26 11:20:59] [EMAIL PROTECTED] > People who do like the shorthand method > will no longer have to write code using an > optional tag style which requires an ini > setting which is NOT set on every(or > even most?) servers. ..and which tag is not XML safe. BTW is still not XML safe, so this is not a real argument ;) XML 1.0 specifies PIs: 'http://bugs.php.net/16763 -- Edit this bug report at http://bugs.php.net/?id=16763&edit=1
Bug #16763 Updated: '
ID: 16763 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: ALL PHP Version: 4.2.0 New Comment: > People who do like the shorthand method > will no longer have to write code using an > optional tag style which requires an ini > setting which is NOT set on every(or > even most?) servers. ..and which tag is not XML safe. BTW is still not XML safe, so this is not a real argument ;) XML 1.0 specifies PIs: 'http://bugs.php.net/16763 -- Edit this bug report at http://bugs.php.net/?id=16763&edit=1
Bug #16660 Updated: Documentation bz2 archive format is not appropriate
ID: 16660 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Windows PHP Version: 4.2.0 New Comment: What is the problem with the HTML Help manuals? Why do we go too far?? BTW we already decided to provide .tar.gz files again, just it seems it didn't make it to the generation system... Previous Comments: [2002-04-26 10:29:47] [EMAIL PROTECTED] I think the problem is a lack of choice. bz2 might be better than other formats, but you (people at php.net) are little going too far with bz2 and that HTML Help... [2002-04-17 12:40:46] [EMAIL PROTECTED] Nope, this is a documentation problem. [2002-04-17 11:42:30] [EMAIL PROTECTED] Reclassified. -Tal [2002-04-17 10:11:32] [EMAIL PROTECTED] Recently there was a change in the archive format of the downloadable documentation - from tar.gz and zip to bz2. A link to a FAQ article describing archive programs for the Windows platform was added in the left pane of http://www.php.net/download-docs.php . The bz2 format is new and not common on Windows platform - which is used by the majority of php users and programmers. Furthermore, the linked programs "Ultimate Zip" and "Quickzip" do not work properly with bz2. Using the bz2 format violates the rule of "least astonishment" and is harmful to the positive image of PHP as being user friendly. Thus I propose to return to tar.gz or .zip format for the doc files. -- Edit this bug report at http://bugs.php.net/?id=16660&edit=1
Bug #16790 Updated: Installation instructions is outdated
ID: 16790 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Windows PHP Version: 4.2.0 New Comment: We have just released this new version, and had no time to update the docs for Windows. Sorry for the inconvinience. Can someone get on this job? Goba Previous Comments: [2002-04-24 07:42:52] [EMAIL PROTECTED] I tried to install the new PHP 4.2 on my Windows 2000 server and found several things in the installation manual that where out of date. The manual I refer to in this report is the following: http://www.php.net/manual/en/install-windows.php When I use the zip file (not the installer) downloaded from php.net I run into these problems: - The manual does not say anything about where to get the "php.exe" file. The only "php.exe" file in the zip package is located in the "sapi" directory, and I do therefore not believe that it is this one I should use. - There is a new directory called "experimental". It seems to hold all the experimental extensions (in prev. versions I believe that they where located in the "extensions" directory like all the others). This should also be in the manual (i.e. tell the user to copy the experimental extensions wanted to the "extensions" directory or set the extension path to point to this directory also). - "extensions/php_gd.dll" does no longer exist. I guess it's now called "extensions/php_gd2.dll". Both the php.ini file and the documentation lacks this information. I don't know if there are anything more then this, but it seems like this manual is from one of the PHP 4.0.? versions. /watson -- Edit this bug report at http://bugs.php.net/?id=16790&edit=1
Bug #16792 Updated: [chm] bug on features.http-auth.html
ID: 16792 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: windows PHP Version: 4.1.2 New Comment: What OS do you exactly use? What IE do you have installed. Aren't there errors on other pages? This error should pop up on all pages all the time, or nowhere, or on all pages sometimes, depending on what is the real error ;) (Note for phpdoc bug readers: this is the form of bug reports from the new chms. I hope it is good enough. I have included automations to post page names and CHM dates for guys to be able to trace if this error is corrected since that CHM release or not.) Previous Comments: [2002-04-24 09:14:07] [EMAIL PROTECTED] I have found a bug on page features.http-auth.html [chm date: 2002-04-20]... I found at least 2 bugs with the same message reported: 'document.all.unotes' is null or not an object Reported on openning following items: "HTTP authentication with PHP" and "Function reference" items on line 3, char 25. Manual php_manual_en.chm distributed in php_manual_sample_5.zip -- Edit this bug report at http://bugs.php.net/?id=16792&edit=1
Bug #16687 Updated: Constants not being interpreted in "variable variables"
ID: 16687 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Red Hat Linux 7.1 PHP Version: 4.2.0 New Comment: Superglobals are named autoglobals or "auto global"s in many cases. Because you need not use "global" to make it global... I personaly think that superglobal is a better name for them (as used by Rasmus first AFAIK), so I use this name. -- Goba Previous Comments: [2002-04-19 21:01:49] [EMAIL PROTECTED] By design ? hehe Ok, I *think* it was not 'by design', I think this just turned out to be the way it is after it has been implemented. I don't think while writing the code and was kept in mind 'no, we do not want them not to be accessible in functions with variable variables'. Ok, so much. Versions of PHP has already been released, so we should document it. Btw, goba, using the search on php.net I couldn't find a single page refering to the super globals ... ? (I haven't yet browser through the manual index as I tend to find that annyoing) [2002-04-19 15:17:41] [EMAIL PROTECTED] I have already reported this problem, but nothing happened. Superglobals seemed to be accessible with variable variables in the global scope, but not in any local scope (inside a function). Derick told me, that it is by design, but IMHO this is incosistent, and quite ugly :(( -- Goba [2002-04-19 14:53:51] [EMAIL PROTECTED] Reclassified. It should be documented that due the special way super globals are treated the cannot be used with variable variables. [2002-04-19 12:40:50] [EMAIL PROTECTED] True true. Derick (or someone else) mind briefly explaining why this is/has to be different? [2002-04-19 11:11:00] [EMAIL PROTECTED] But then why does it work under certain circumstances and not others? Regardless whether intended or not, this is inconsistent behaviour. I also think that having these differences between regular variables and the "superglobals" shouldn't be necessary. If I can't use them in the same contexts as regular variables, then I would personally prefer the $HTTP_*_VARS instead, because you can. I have found my approach to abstracting this difference ($HTTP_*_VARS vs. $_*) between PHP versions to be really beneficial to my scripts. I can abstract them both down to one name, and use a single reference to the appropriate one instead of sticking if statements every time I need to know which one to use. Sorry to keep buggin' ya, but I think this may be a fair enough argument for change. 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/16687 -- Edit this bug report at http://bugs.php.net/?id=16687&edit=1
Bug #16687 Updated: Constants not being interpreted in "variable variables"
ID: 16687 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Red Hat Linux 7.1 PHP Version: 4.2.0 New Comment: I have already reported this problem, but nothing happened. Superglobals seemed to be accessible with variable variables in the global scope, but not in any local scope (inside a function). Derick told me, that it is by design, but IMHO this is incosistent, and quite ugly :(( -- Goba Previous Comments: [2002-04-19 14:53:51] [EMAIL PROTECTED] Reclassified. It should be documented that due the special way super globals are treated the cannot be used with variable variables. [2002-04-19 12:40:50] [EMAIL PROTECTED] True true. Derick (or someone else) mind briefly explaining why this is/has to be different? [2002-04-19 11:11:00] [EMAIL PROTECTED] But then why does it work under certain circumstances and not others? Regardless whether intended or not, this is inconsistent behaviour. I also think that having these differences between regular variables and the "superglobals" shouldn't be necessary. If I can't use them in the same contexts as regular variables, then I would personally prefer the $HTTP_*_VARS instead, because you can. I have found my approach to abstracting this difference ($HTTP_*_VARS vs. $_*) between PHP versions to be really beneficial to my scripts. I can abstract them both down to one name, and use a single reference to the appropriate one instead of sticking if statements every time I need to know which one to use. Sorry to keep buggin' ya, but I think this may be a fair enough argument for change. [2002-04-19 10:33:59] [EMAIL PROTECTED] You can't use superglobals indirectly, check this: $t = "_GET"; var_dump ($$t); doesn't work neither, and it wasn't supposed to work. However, this does work (because $HTTP_GET_VARS is not a superglobal): $t = "HTTP_GET_VARS"; var_dump ($$t); Derick [2002-04-18 19:09:09] [EMAIL PROTECTED] reclassified 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/16687 -- Edit this bug report at http://bugs.php.net/?id=16687&edit=1
Bug #16632 Updated: Introductory Tutorial tut.php uses $HTTP_USER_AGENT
ID: 16632 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type:Documentation problem PHP Version: 4.2.0 New Comment: The plan was to integrate the intro into the manual, and extend it in some basic areas Previous Comments: [2002-04-16 07:17:28] [EMAIL PROTECTED] Shouldn't we change the default tutorial at the url below so that it works with both PHP 4.0.x and 4.1.x? http://www.php.net/tut.php Bye, John -- Edit this bug report at http://bugs.php.net/?id=16632&edit=1
Bug #16525 Updated: Cannot open the file: mk:@MSITStore:......
ID: 16525 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: Windows PHP Version: 4.1.2 New Comment: Please check if it is in a directory with no # or any other URL special character in the name. Goba Previous Comments: [2002-04-10 02:00:27] [EMAIL PROTECTED] I just download Windows HTML Help file (Size: 5288Kb Date: 9 Apr 2002) from http://www.php.net/download-docs.php?sizes=1, but I don't can to see it. When I try to see (run) he, appear popup window asked next: Cannot open the file: mk:@MSITStore:.. -- Edit this bug report at http://bugs.php.net/?id=16525&edit=1
Bug #16476 Updated: unpacking
ID: 16476 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Windows 2000 PHP Version: 4.1.2 New Comment: How many zip programs do you need to setup depends on what you already have. We have some recommendations for Windows users in our FAQ. My question was what is the error message. It seems nothing... :(( That does not help too much. Can anyone form the doc or dev team please test a bz2 manual on Win2k with actual bz2 tools? Goba Previous Comments: [2002-04-07 13:45:47] [EMAIL PROTECTED] My problem is _exact_ as described I could not extract the file. The bzip2 "chew" on the file for a while and then returned without any responce, _no_ files were extracted ! >> Bzip2 is much smaller, and it works. Well, why not wait using that kind of stuff until an update for the WinZip and WinRara _both_ have been released, so we do not need to install god know how many different package programs ? Thanks Olrik Larsen [2002-04-07 12:48:16] [EMAIL PROTECTED] Bzip2 is much smaller, and it works. What is your exact problem? The solution should be found, insted of trying to work around your problem... Goba [2002-04-07 11:13:05] [EMAIL PROTECTED] I am unable to decompress the manuals compressed with bzip2 I have downloaded the latest bzip2 program but it still doesnt work. Please go back to .tar format or some other usefull like .zip, .rar .arj Regs. Olri Larsen -- Edit this bug report at http://bugs.php.net/?id=16476&edit=1
Bug #16476 Updated: unpacking
ID: 16476 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Windows 2000 PHP Version: 4.1.2 New Comment: Bzip2 is much smaller, and it works. What is your exact problem? The solution should be found, insted of trying to work around your problem... Goba Previous Comments: [2002-04-07 11:13:05] [EMAIL PROTECTED] I am unable to decompress the manuals compressed with bzip2 I have downloaded the latest bzip2 program but it still doesnt work. Please go back to .tar format or some other usefull like .zip, .rar .arj Regs. Olri Larsen -- Edit this bug report at http://bugs.php.net/?id=16476&edit=1
Bug #16447 Updated: Inactive "see alsos"
ID: 16447 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Documentation problem Operating System: n/a PHP Version: 4.1.2 Assigned To: cortesi New Comment: I think Simone thought "by making the XML lowercase"... This is not the ultimate solution though... Hartmut added auto-lowercase support for links into XSL sheets. BTW if someone can test the XSL sheets outputs, I can add any features needed to be conform to the DSSSL output. I have already done the phpweb sheet. Previous Comments: [2002-04-05 07:27:55] [EMAIL PROTECTED] by changing the XML or by making the style sheets case-insensitive? [2002-04-05 06:46:09] [EMAIL PROTECTED] I will fix it this afternoon [2002-04-05 05:52:29] [EMAIL PROTECTED] I think case sensitivity is the problem here (works fine in de/ translation where the function names aall lowercased) [2002-04-05 05:44:53] [EMAIL PROTECTED] Again image.xml, functions ImageGIF, ImageJPEG and probably some other. There are "see alsos" in those functions, that are not links. I don't have time to investigate it now, so I put a report only. -- Edit this bug report at http://bugs.php.net/?id=16447&edit=1
Bug #16234 Updated: important language features only mentioned in passing
ID: 16234 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Documentation problem Operating System: WinXP PHP Version: 4.1.2 New Comment: For global and static to appear in the CHM index, and be used as php.net/global, these two keywords should have their own pages in the manual (eg. sect1.) Reopening, Goba Previous Comments: [2002-03-24 11:24:53] [EMAIL PROTECTED] I should have mentioned, I'm referring to the index of the CHM. The CHM people said to post it here because it was content related..? [2002-03-24 06:10:06] [EMAIL PROTECTED] "global" as well as "static" are listed in the "List of Keywords" (http://at.php.net/manual/en/reserved.php), and are described in the Language Reference (exactly Variable Scope, http://at.php.net/manual/en/language.variables.scope.php), which is also linked from the Keyword-list. [2002-03-23 11:49:07] [EMAIL PROTECTED] There is no page for the keywords "global" or "static". Neither can be found in the index. There are many things like this that are only mentioned in passing, without having an actual definition. -- Edit this bug report at http://bugs.php.net/?id=16234&edit=1
Bug #16241 Updated: make apache error
ID: 16241 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Website problem +Bug Type: Apache related Operating System: sun5.5.1 PHP Version: 4.1.2 New Comment: This is not a PHP.net website problem, but an Apache problem... Previous Comments: [2002-03-24 05:06:48] [EMAIL PROTECTED] ld: fatal: Symbol referencing errors. No output written to httpd *** Error code 1 make: Fatal error: Command failed for target `target_static' Current working directory /home/personal-http/mail/apache/apache/src *** Error code 1 make: Fatal error: Command failed for target `build-std' Current working directory /home/personal-http/mail/apache/apache *** Error code 1 make: Fatal error: Command failed for target `build' But I use php4.0B on sun site,It is oki? but readdir() can not use! so I install CVS php,but errors happen like before! My english is not well. [2002-03-24 04:50:27] [EMAIL PROTECTED] when I make apache ,error happen! I use sunos5.5.1,gcc2.7.2.1,gunmake <=== src/modules/php4 <=== src/modules gcc -c -I./os/unix -I./include -DSOLARIS2=251 -I/home/personal-http/mail/apache/php -I/home/personal-http/mail/apache/php/main -I/home/personal-http/mail/apache/php/main -I/home/personal-http/mail/apache/php/Zend -I/home/personal-http/mail/apache/php/Zend -I/home/personal-http/mail/apache/php/TSRM -I/home/personal-http/mail/apache/php/TSRM -I/home/personal-http/mail/apache/php -DUSE_EXPAT -I./lib/expat-lite `./apaci` modules.c gcc -c -I./os/unix -I./include -DSOLARIS2=251 -I/home/personal-http/mail/apache/php -I/home/personal-http/mail/apache/php/main -I/home/personal-http/mail/apache/php/main -I/home/personal-http/mail/apache/php/Zend -I/home/personal-http/mail/apache/php/Zend -I/home/personal-http/mail/apache/php/TSRM -I/home/personal-http/mail/apache/php/TSRM -I/home/personal-http/mail/apache/php -DUSE_EXPAT -I./lib/expat-lite `./apaci` buildmark.c gcc -DSOLARIS2=251 -I/home/personal-http/mail/apache/php -I/home/personal-http/mail/apache/php/main -I/home/personal-http/mail/apache/php/main -I/home/personal-http/mail/apache/php/Zend -I/home/personal-http/mail/apache/php/Zend -I/home/personal-http/mail/apache/php/TSRM -I/home/personal-http/mail/apache/php/TSRM -I/home/personal-http/mail/apache/php -DUSE_EXPAT -I./lib/expat-lite `./apaci`\ -o httpd buildmark.o modules.o modules/php4/libphp4.a modules/standard/libstandard.a main/libmain.a ./os/unix/libos.a ap/libap.a lib/expat-lite/libexpat.a -R/usr/ucblib -R/opt/GCC2721/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.1 -L/usr/ucblib -L/opt/GCC2721/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.1 -Lmodules/php4 -L../modules/php4 -L../../modules/php4 -lmodphp4 -ldl -lcrypt -lresolv -lresolv -lresolv -lm -ldl -lnsl -lsocket -lsocket -lgcc -lcrypt -lsocket -lnsl Undefined first referenced symbol in file readdir64_r modules/php4/libphp4.a(reentrancy.o) -- Edit this bug report at http://bugs.php.net/?id=16241&edit=1
Bug #16137 Updated: ini_set / error_reporting inconsistence
ID: 16137
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: PHP options/info functions
Operating System: win2k
PHP Version: 4.1.0
New Comment:
I have not tested this with ini_get, but IMHO
a) error_reporting() should be an alias for
ini_get("error_reporting")
and
b) error_reporting(E_ALL) should be an alias for
ini_set("error_reporting", E_ALL)...
Goba
Previous Comments:
[2002-03-18 04:20:46] [EMAIL PROTECTED]
Consider the code below, with error_repoting set to
E_ALL (2047) before the script start:
" . $new;
//ini_set("error_reporting", $new);
phpinfo();
?>
This would set the error_reporting to 2046,
as returned and injected to the $new variable.
BUT phpinfo() will present 2047 as the local
value, instead of 2046. If you uncomment the
ini_set() call, you get the correct 2046 in the
phpindo() output. So error_repoting(..) and
ini_set("error_reporting"..) are not the same ;((
--
Edit this bug report at http://bugs.php.net/?id=16137&edit=1
Bug #16066 Updated:
ID: 16066 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux (Debian) PHP Version: 4.1.1 New Comment: Goba Previous Comments: [2002-03-18 04:07:26] [EMAIL PROTECTED] I totally agree that you is horrible. The reason I found this problem was that I was commenting out a section of HTML using PHP tags. I just stuck in but it confused me when it didn't work. If this space is a requirement it really should be mentioned somewhere in the documentation. I'm going to stick a comment on the "Basic Syntax" section of the manual, where it talks about these tags. I do still think they should all be consistant though. ;o) [2002-03-15 21:06:49] [EMAIL PROTECTED] Apperently, short tag does not need spaces after open tag :) However, there is nothing wrong and there is nothing we should fix here. i.e. Changing " while is not. [2002-03-15 07:46:38] [EMAIL PROTECTED] Funny... If (as you claim) this: is not a PHP script, howcome PHP actually prints out "Hello" in this situation? (with no warnings or errors) Is PHP in the habit of running code that is "not PHP script" ? So far both of your reasons for marking this bug as "bogus" have contradicted this example, which was in my original bug report and is something you could easily reproduce yourself. This gives me the impression that either you've not bothered reading my comments, you haven't understood what I'm saying or you think its not important enough to be worth fixing so you're making up lame excuses. Please read this bug report properly and think about it before marking it as "bogus" again. If you don't understand it or can't be bothered with it please refer it to someone who does/can, rather than just closing it. Whatever response you do give, PLEASE make sure it doesn't contradict something I've already explained, that is very frustrating. [2002-03-15 06:59:01] [EMAIL PROTECTED] PHP will not raise error since it's not PHP script. There is no way to raise error, if it's not a PHP script. [2002-03-15 05:27:51] [EMAIL PROTECTED] You say you must have a space after does not report an error, either way something is wrong here, because the behaviour is not consistant for all three of those tokens. I have looked at "Chapter 5. Basic syntax" section of the manual, this explains the use of the http://bugs.php.net/16066 -- Edit this bug report at http://bugs.php.net/?id=16066&edit=1
Bug #16138: .htaccess / httpd.conf and error_reporting constants
From: [EMAIL PROTECTED] Operating system: win2k PHP version: 4.1.0 PHP Bug Type: *Configuration Issues Bug description: .htaccess / httpd.conf and error_reporting constants Let's put this into a .htaccess (I guess it is the same inside httpd.conf, but not tried): php_value error_reporting E_ALL Run the following PHP code in the same dir: The echo will print out zero, but PHPinfo() will present the string "E_ALL" as the local value. Error reporting constants should be handled in .htaccess files IMHO... -- Edit bug report at http://bugs.php.net/?id=16138&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16138&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16138&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16138&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16138&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16138&r=support Expected behavior: http://bugs.php.net/fix.php?id=16138&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16138&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16138&r=submittedtwice
Bug #16137: ini_set / error_reporting inconsistence
From: [EMAIL PROTECTED]
Operating system: win2k
PHP version: 4.1.0
PHP Bug Type: PHP options/info functions
Bug description: ini_set / error_reporting inconsistence
Consider the code below, with error_repoting set to
E_ALL (2047) before the script start:
" . $new;
//ini_set("error_reporting", $new);
phpinfo();
?>
This would set the error_reporting to 2046,
as returned and injected to the $new variable.
BUT phpinfo() will present 2047 as the local
value, instead of 2046. If you uncomment the
ini_set() call, you get the correct 2046 in the
phpindo() output. So error_repoting(..) and
ini_set("error_reporting"..) are not the same ;((
--
Edit bug report at http://bugs.php.net/?id=16137&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16137&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16137&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16137&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16137&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16137&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16137&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16137&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16137&r=submittedtwice
Bug #13321 Updated: Documnetation
ID: 13321 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Win 32 PHP Version: 4.0.6 New Comment: Nice ;) Who will volunteer to find this out? Goba Previous Comments: [2002-03-09 00:22:18] [EMAIL PROTECTED] Filesystem functions that contain the &no-windows; entity are as follows: chgrp, chmod, chown, filegroup, fileinode, fileowner, is_link, link, linkinfo, readlink, symlink, umask The question is, which work now and when did they begin to work? And to go beyond this bug, how about making available a list of all win32/linux "differences", in relation to PHP. There are a few, like slashes, \newlines, various functions, sendmail_from directive, etc. [2002-03-09 00:00:01] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-02-06 12:13:56] [EMAIL PROTECTED] Examples? More info needed than that! [2001-09-15 13:11:45] [EMAIL PROTECTED] Many of the file function in the manual now works on Win32 Sure you know that, but the manual is not updated. -- Edit this bug report at http://bugs.php.net/?id=13321&edit=1
Bug #15810 Updated: superglobals does not work with dynamic vars in functions
ID: 15810
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Feature/Change Request
Operating System: win2k
PHP Version: 4.1.0
New Comment:
The strange thing is that it works in global scope, but not in function
scope. I quess people will try to use this for similar thing such as
$var = "HTTP_" . $method . "_VARS";
global $$var;
$form = $$var;
or
$form = $GLOBALS["HTTP_" . $method . "_VARS"];
But using
$form = ${"_$method"};
is much more simple, and requires no globals...
This is inconsistent as it works outside of functions
but not inside of functions, although we advertise
the superglobals, as they behave the same inside
or outside any scope... I hit this 'bug' because I wanted
to use exactly this short thing...
Previous Comments:
[2002-03-01 09:55:30] [EMAIL PROTECTED]
It was not supposed to work, so I'm making this a feature request.
If you want I can dig up some old mail / chat logs about this...
Derick
[2002-03-01 09:51:27] [EMAIL PROTECTED]
See the attached example. The first print_r() in the
function does not print out anything, while the second
prints out the contents of $_GET. I have set $_GET to a
dummy array to let you test without a server.
Conclusion: dynamic names does not work for superglobals
in functions (I have also tested them in methods, but
these handled the same as functions...). Though
dynamic names work in global scope for superglobals...
--
Edit this bug report at http://bugs.php.net/?id=15810&edit=1
Bug #15810: superglobals does not work with dynamic vars in functions
From: [EMAIL PROTECTED] Operating system: win2k PHP version: 4.1.0 PHP Bug Type: Scripting Engine problem Bug description: superglobals does not work with dynamic vars in functions See the attached example. The first print_r() in the function does not print out anything, while the second prints out the contents of $_GET. I have set $_GET to a dummy array to let you test without a server. Conclusion: dynamic names does not work for superglobals in functions (I have also tested them in methods, but these handled the same as functions...). Though dynamic names work in global scope for superglobals... -- Edit bug report at http://bugs.php.net/?id=15810&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15810&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15810&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15810&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15810&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15810&r=support Expected behavior: http://bugs.php.net/fix.php?id=15810&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15810&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15810&r=submittedtwice
Bug #15777 Updated: REMOTE_USER
ID: 15777 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Solaris PHP Version: 4.1.2 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Previous Comments: [2002-02-28 05:19:25] [EMAIL PROTECTED] anyone know when REMOTE_USER is not empty? Tried to capture it in a Solaris/Apache server, only got REMOTE_ADDR pointed to the remote IP, REMOTE_USER always empty, tried it in perl, in PHP, always failed to get anything. Are these controled by my local windows/browsers or apache in the server? -- Edit this bug report at http://bugs.php.net/?id=15777&edit=1
Bug #15728 Updated: about still notes .tgz and .zip formats of manual
ID: 15728 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: n/a PHP Version: 4.1.1 New Comment: This bug has been fixed in CVS. Previous Comments: [2002-02-26 04:20:45] [EMAIL PROTECTED] On http://www.php.net/manual/en/about.php the .tgz and .zip distributions of the html and plaintext manual are still noted although they're no longer available. -- Edit this bug report at http://bugs.php.net/?id=15728&edit=1
Bug #15724 Updated: Installing PHP as a module - documentation error
ID: 15724 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Windows PHP Version: 4.1.1 New Comment: This is describen on the Apache-Windows page for a long time now... Please read the manual carefully. Previous Comments: [2002-02-26 02:38:53] [EMAIL PROTECTED] To whom it may concern, I recently downloaded PHP for windows, as a binary file. I also installed apache 1.3.x for windows and set it up to run as a service. Now, I wanted to run php as a module for apache so I used the install guide provided. The guide failed to state that once you add in the: LoadModule php4_module c:/php/SAPI/php4apache.dll AddType application/x-httpd-php .php You must also add in a line to the "Addmodule" section directly below, namely: AddModule mod_php4.c Otherwise you are returned with an error: [error] Cannot remove module mod_php4.c: not found in module list This error won't allow apache to send php the .php scripts to interpret them. Thus showing a blank screen. It's a minor oversight, but to a fledgling PHP'er it could be a put off from using php or apache. Yours, Huw Dowden -- Edit this bug report at http://bugs.php.net/?id=15724&edit=1
Bug #15609 Updated: missing directive in documentation
ID: 15609 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: windows PHP Version: 4.1.1 Assigned To: imajes New Comment: This is included at http://www.php.net/manual/en/install.apache.php I don't have php4 module Karma to commit the note there to... This does not mean you need the C source of course, but ClearModuleList clears up the list, and it only works with the mod_php4.c line included... Previous Comments: [2002-02-19 03:34:16] [EMAIL PROTECTED] you don't need to include the original c source file, that's kinda madness. i'll check the install.txt again to see. [2002-02-18 20:31:37] [EMAIL PROTECTED] In the installation guide file (install.txt) under the install for apache section, the lines listed are LoadModule php4_module c:/php/sapi/php4apache.dll and AddType application/x-httpd-php .php but for PHP to work like this, another line must be added to httpd.conf: AddModule mod_php4.c this is the line I used, although I am not sure it must be mod_php4.c; anyway, I only figured this out by guesswork. Just needs to be added to the documentation. -- Edit this bug report at http://bugs.php.net/?id=15609&edit=1
Bug #15603 Updated: PHP output sometimes doesn't follow HTML 4.01 standards.
ID: 15603 Updated by: [EMAIL PROTECTED] -Summary: PHP output sometimes doesn't follow HTML 4.01 standards. Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Documentation problem Operating System: Linux PHP Version: 4.0.5 New Comment: use ini_set() then Previous Comments: [2002-02-18 16:11:12] [EMAIL PROTECTED] I know, but I'm not in a position to chose. I'm a customer at a hosting company. [2002-02-18 16:04:46] [EMAIL PROTECTED] You can change this with arg_separator.output ini directive. >From php.ini-dist: ; The separator used in PHP generated URLs to separate arguments. ; Default is "&". ;arg_separator.output = "&" (you should also update to PHP 4.1.1) Reclassified as docu prob since this is not mentioned on the session docs. (or in the configuration part either) --Jani [2002-02-18 15:47:12] [EMAIL PROTECTED] When use-cookies is set to Off or when the possibility to use them doesn't exist, PHP adds the session variable to links on the outputted HTML-page. The link may look like this: There's a problem with the above link - it doesn't follow the standards. This is easy to fix, just change & to & I don't consider this some huge disadvantage but it could be fixed. -- Edit this bug report at http://bugs.php.net/?id=15603&edit=1
