Req #46182 [Com]: mysql_connection_reused( $link) function
Edit report at http://bugs.php.net/bug.php?id=46182&edit=1
ID: 46182
Comment by: ninzya at inbox dot lv
Reported by:ninzya at inbox dot lv
Summary:mysql_connection_reused( $link) function
Status: Wont fix
Type: Feature/Change Request
Package:MySQL related
Operating System: Any
PHP Version:5.3.0alpha2
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Thank you for the info.
Previous Comments:
[2011-01-06 16:06:17] u...@php.net
Reusing of not properly cleaned up persistent connections is an evil
aside effect that's confusing many beginners. mysqli gives you the
choice if you want connections that are put into the persistent pool
always to be cleaned up and appear as if they had been just opened
(default) or to return them in the state the previous user as left them
when the connection was put into the persistent pool - with all the
dirty side effects: authentication changes are not detected,
transactions can be open, variables are not cleared up, temporary tables
are there etc. . mysqli makes a clear cut and calls mysql_change_user()
(C API = mysqli_change_user() PHP mysqli) before reusing a connection.
Its always cleaned up. That's a safe choice for 90% of the users. Only
some power users who know what they do should require the ext/mysql
behaviour. And those power users don't need an extra API call because
you can hack something using SQL connection variables:
SELECT @connection_init
if @connection_init = 0
INIT stuff
SET @connection_init = 1
[2008-09-26 13:24:06] ninzya at inbox dot lv
Description:
It would be great if we had mysql_connection_reused( $link) function,
which returned boolean value if just established connection was
reused or no.
Reproduce code:
---
$link =mysql_pconnect( $host .':' .$port, $user, $pass);
if( !mysql_connection_reused( $link)) {
mysql_query( 'SET NAMES utf8;');
mysql_query( 'USE mydb;');
} else {
// connection was reused, don't do any initialization queries,
// because they were already made by another request
}
Expected result:
This would allow to optimize database load on heavy loaded servers.
Actual result:
--
Not implemented
--
Edit this bug report at http://bugs.php.net/bug.php?id=46182&edit=1
[PHP-BUG] Bug #53701 [NEW]: T_USE should not be available on PHP 5.2
From: Operating system: Windows PHP version: 5.2.17 Package: Scripting Engine problem Bug Type: Bug Bug description:T_USE should not be available on PHP 5.2 Description: While I worked on a new version of PHP_CompatInfo, I've found that the token T_USE is available on at least PHP 5.2.13 version. If keyword "use" is only related to namespace, as this last one is only available since PHP 5.3, it should not be present. http://www.php.net/manual/en/tokens.php Regards Laurent Laville http://pear.php.net/user/farell Test script: --- Expected result: T_USE token not available Actual result: -- ) [tokenizer] => Array ( ... [T_USE] => 339 ... -- Edit bug report at http://bugs.php.net/bug.php?id=53701&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53701&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53701&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53701&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53701&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53701&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53701&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53701&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53701&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53701&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53701&r=support Expected behavior: http://bugs.php.net/fix.php?id=53701&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53701&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53701&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53701&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53701&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53701&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53701&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53701&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53701&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53701&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53701&r=mysqlcfg
Bug #53460 [Com]: glob() returns false for a pattern that matches zero files
Edit report at http://bugs.php.net/bug.php?id=53460&edit=1
ID: 53460
Comment by: 13550 at free dot fr
Reported by:cameel2+php at gmail dot com
Summary:glob() returns false for a pattern that matches zero
files
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: Arch Linux
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
"array() == false" is true because array is empty
try var_dump($glob) to be sure that glob does not return an array
Previous Comments:
[2010-12-03 17:41:27] cameel2+php at gmail dot com
Yeah, I meant that since I tested it under Apache first and that
directory is located in /srv/http, i.e. in the root directory of the
server.
But you're right - for php being run from command line I should have
used relative path. Still, when I remove the leading slash and run
cd /srv/http; php test.php
the result is still false.
This is a contrived example anyway. Originally I have noticed it in a
more complex path.
If I do
touch /srv/http/phpMyAdmin/a.file
the script starts printing 'array'.
[2010-12-03 12:53:57] paj...@php.net
Are you sure you mean $glob = glob('/phpMyAdmin/*'); and not $glob =
glob('phpMyAdmin/*');? The sooner is an absolute path '/phpMyAdmin/',
where the 2nd path is relative (to CWD).
[2010-12-03 05:56:59] cameel2+php at gmail dot com
Description:
On my system the glob() returns false if there are no files matching the
pattern even though the documentation
(http://php.net/manual/en/function.glob.php) states that it should
return an empty array.
PHP version: 5.3.3
The only things I have changed in php.ini are open_basedir
(/srv/http/:/home/:/usr/share/webapps:/etc/webapps:/tmp/:/usr/share/pear/:/usr/share/symfony)
and enabling of several extensions (mcrypt, mysql, pdo, pdo_sqlite).
I've seen similar bugs reported and closed a few years ago: #29928
Test script:
---
Expected result:
glob() should return an empty array if no files match the pattern.
Actual result:
--
The script prints 'false' when run on my box (both under Apache 2.2.17
and with php from command line).
--
Edit this bug report at http://bugs.php.net/bug.php?id=53460&edit=1
Bug #53460 [Opn]: glob() returns false for a pattern that matches zero files
Edit report at http://bugs.php.net/bug.php?id=53460&edit=1
ID: 53460
User updated by:cameel2+php at gmail dot com
Reported by:cameel2+php at gmail dot com
Summary:glob() returns false for a pattern that matches zero
files
Status: Open
Type: Bug
-Package:Filesystem function related
+Package:*Directory Services problems
Operating System: Arch Linux
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Right. But in that case the script would be printing both 'false' and
'array'. It prints only 'false'.
I have just added var_dump() at the end of the test case and now the
output is:
false
bool(false)
BTW: I am using PHP 5.3.5 now.
Previous Comments:
[2011-01-09 17:56:43] 13550 at free dot fr
"array() == false" is true because array is empty
try var_dump($glob) to be sure that glob does not return an array
[2010-12-03 17:41:27] cameel2+php at gmail dot com
Yeah, I meant that since I tested it under Apache first and that
directory is located in /srv/http, i.e. in the root directory of the
server.
But you're right - for php being run from command line I should have
used relative path. Still, when I remove the leading slash and run
cd /srv/http; php test.php
the result is still false.
This is a contrived example anyway. Originally I have noticed it in a
more complex path.
If I do
touch /srv/http/phpMyAdmin/a.file
the script starts printing 'array'.
[2010-12-03 12:53:57] paj...@php.net
Are you sure you mean $glob = glob('/phpMyAdmin/*'); and not $glob =
glob('phpMyAdmin/*');? The sooner is an absolute path '/phpMyAdmin/',
where the 2nd path is relative (to CWD).
[2010-12-03 05:56:59] cameel2+php at gmail dot com
Description:
On my system the glob() returns false if there are no files matching the
pattern even though the documentation
(http://php.net/manual/en/function.glob.php) states that it should
return an empty array.
PHP version: 5.3.3
The only things I have changed in php.ini are open_basedir
(/srv/http/:/home/:/usr/share/webapps:/etc/webapps:/tmp/:/usr/share/pear/:/usr/share/symfony)
and enabling of several extensions (mcrypt, mysql, pdo, pdo_sqlite).
I've seen similar bugs reported and closed a few years ago: #29928
Test script:
---
Expected result:
glob() should return an empty array if no files match the pattern.
Actual result:
--
The script prints 'false' when run on my box (both under Apache 2.2.17
and with php from command line).
--
Edit this bug report at http://bugs.php.net/bug.php?id=53460&edit=1
[PHP-BUG] Req #53702 [NEW]: unregister_shutdown_function() or similar
From: Operating system: n/a PHP version: Irrelevant Package: Unknown/Other Function Bug Type: Feature/Change Request Bug description:unregister_shutdown_function() or similar Description: It'd be useful to have unregister_shutdown_function() implemented similarly to how unregister_tick_function() works, but it would require to accept callback as a parameter and not just the function name. -- Edit bug report at http://bugs.php.net/bug.php?id=53702&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53702&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53702&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53702&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53702&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53702&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53702&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53702&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53702&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53702&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53702&r=support Expected behavior: http://bugs.php.net/fix.php?id=53702&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53702&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53702&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53702&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53702&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53702&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53702&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53702&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53702&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53702&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53702&r=mysqlcfg
Req #23723 [Com]: Extend strip_tags()
Edit report at http://bugs.php.net/bug.php?id=23723&edit=1
ID: 23723
Comment by: jthijssen at noxlogic dot nl
Reported by:eric at evilwalrus dot com
Summary:Extend strip_tags()
Status: Assigned
Type: Feature/Change Request
Package:Strings related
Operating System: *
PHP Version:*
Assigned To:moriyoshi
Block user comment: N
Private report: N
New Comment:
I know it's a (very) old bug, but on occasion I need a "blacklist"
intead of a "whitelist" strip_tags() function.
I've created a patch with an addtional bool to strip_tags() with which
you can use the $allowable_tags parameter as a blacklist instead of a
whitelist.
Examples:
strip_tags('Clickhere', ''); => Clickhere
strip_tags('Clickhere', '', false); => Clickhere
Previous Comments:
[2003-05-20 13:47:14] eric at evilwalrus dot com
Right now strip_tags() is a great function. You specify a string and the
tags you want to keep. What I would like to see is another argument in
strip tags so that you could tell it to keep or remove the tags you
specify. I saw bug #5976 that had something to do with this very
thought, but this extends the idea further. For example, if I have a
string full of HTML and I want to remove all
Bug #51458 [Com]: Lack of error context with nested exceptions
Edit report at http://bugs.php.net/bug.php?id=51458&edit=1 ID: 51458 Comment by: sailormax at inbox dot lv Reported by:nlgordon at gmail dot com Summary:Lack of error context with nested exceptions Status: Open Type: Bug Package:Unknown/Other Function Operating System: Redhat Linux PHP Version:5.3.2 Block user comment: N Private report: N New Comment: same problem with 5.2.x after 5.2.5; I had calling unexist function in exception handler. In result PHP returned empty page and didn't write any error in logs. Not very comfortable debug scripts in such conditions... :/ Previous Comments: [2010-04-01 23:15:54] nlgordon at gmail dot com Description: In short, if you thrown an exception from within the exception handler, you get an uninformative error message with no contextual information. It makes sense for this case to be a fatal error. We don't want to get recursive throwing of exceptions and spiral to our death. If you create an exception in the error handler without throwing it, it has the correct info about where it was created. This is enough to figure out where the error is coming from. It is at least far more informative and gives you a starting place in a potentially complex code base. >From my quick look at the code in Zend/zend_exceptions.c:94 where this originates. It looks like the exception is there, and that would have file/line num info. Test script: --- http://bugs.php.net/bug.php?id=51458&edit=1
Bug #53513 [Com]: PHP 5.3.4 does not copy pear, peardev and pecl binaries into place.
Edit report at http://bugs.php.net/bug.php?id=53513&edit=1 ID: 53513 Comment by: thepixeldeveloper at googlemail dot com Reported by:thepixeldeveloper at googlemail dot com Summary:PHP 5.3.4 does not copy pear, peardev and pecl binaries into place. Status: Feedback Type: Bug Package:Compile Failure Operating System: Ubuntu 10.10 maverick PHP Version:5.3.4 Block user comment: N Private report: N New Comment: The problem didn't appear with 5.3.5. Consider it fixed. Previous Comments: [2010-12-20 13:06:49] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ The configure line you provided worked just fine for me and I did get pear/pecl/etc. as expected.. [2010-12-10 05:27:03] thepixeldeveloper at googlemail dot com Description: PHP 5.3.4 does not put pear, peardev and pecl binaries into the bin directory. ./configure script log - https://gist.github.com/ff52ad3603b7d6999d02 make log - https://gist.github.com/98565ae779cc9f3b5866 make install log - https://gist.github.com/0c7f4078a9e1df11c628 Test script: --- ./configure --prefix=/opt/php-5.3.4 --with-openssl --with-mcrypt --with-mysqli --with-mysql=mysqlnd --with-mysql-sock --with-gd --with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/usr --with-freetype-dir=/usr --with-tidy --with-curl --enable-fpm --enable-gd-native-ttf --enable-gd-jis-conv --enable-mbstring --disable-xmlreader --disable-xmlwriter --disable-phar --without-sqlite --without-sqlite3 --disable-pdo --disable-posix --with-pear=/opt/php-5.3.4/pear --with-pdo-mysql --enable-pdo --without-pdo-sqlite --enable-pcntl Expected result: [mat...@thepixeldeveloper php-5.3.4]$ ls /opt/php-5.3.3/bin/ pear peardev pecl php php-config phpize Actual result: -- [mat...@thepixeldeveloper php-5.3.4]$ ls /opt/php-5.3.4/bin/ php php-config phpize -- Edit this bug report at http://bugs.php.net/bug.php?id=53513&edit=1
Bug #53513 [Fbk->Csd]: PHP 5.3.4 does not copy pear, peardev and pecl binaries into place.
Edit report at http://bugs.php.net/bug.php?id=53513&edit=1 ID: 53513 Updated by: paj...@php.net Reported by:thepixeldeveloper at googlemail dot com Summary:PHP 5.3.4 does not copy pear, peardev and pecl binaries into place. -Status: Feedback +Status: Closed Type: Bug Package:Compile Failure Operating System: Ubuntu 10.10 maverick PHP Version:5.3.4 -Assigned To: +Assigned To:pajoye Block user comment: N Private report: N Previous Comments: [2011-01-09 22:47:29] thepixeldeveloper at googlemail dot com The problem didn't appear with 5.3.5. Consider it fixed. [2010-12-20 13:06:49] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ The configure line you provided worked just fine for me and I did get pear/pecl/etc. as expected.. [2010-12-10 05:27:03] thepixeldeveloper at googlemail dot com Description: PHP 5.3.4 does not put pear, peardev and pecl binaries into the bin directory. ./configure script log - https://gist.github.com/ff52ad3603b7d6999d02 make log - https://gist.github.com/98565ae779cc9f3b5866 make install log - https://gist.github.com/0c7f4078a9e1df11c628 Test script: --- ./configure --prefix=/opt/php-5.3.4 --with-openssl --with-mcrypt --with-mysqli --with-mysql=mysqlnd --with-mysql-sock --with-gd --with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/usr --with-freetype-dir=/usr --with-tidy --with-curl --enable-fpm --enable-gd-native-ttf --enable-gd-jis-conv --enable-mbstring --disable-xmlreader --disable-xmlwriter --disable-phar --without-sqlite --without-sqlite3 --disable-pdo --disable-posix --with-pear=/opt/php-5.3.4/pear --with-pdo-mysql --enable-pdo --without-pdo-sqlite --enable-pcntl Expected result: [mat...@thepixeldeveloper php-5.3.4]$ ls /opt/php-5.3.3/bin/ pear peardev pecl php php-config phpize Actual result: -- [mat...@thepixeldeveloper php-5.3.4]$ ls /opt/php-5.3.4/bin/ php php-config phpize -- Edit this bug report at http://bugs.php.net/bug.php?id=53513&edit=1
[PHP-BUG] Bug #53704 [NEW]: makerpm has incorrect command/spec file has incorrect spelling
From: Operating system: Unix/Linux PHP version: 5.3.5 Package: *General Issues Bug Type: Bug Bug description:makerpm has incorrect command/spec file has incorrect spelling Description: makerpm shell script has (at least) two places,which make rpm spec file unusable. 1. rpmbuild command should be used instead of rpm 2. Copyright needs to be replaced with License Test script: --- just try to create rpm file Expected result: rpm file Actual result: -- nothing! :( -- Edit bug report at http://bugs.php.net/bug.php?id=53704&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53704&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53704&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53704&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53704&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53704&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53704&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53704&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53704&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53704&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53704&r=support Expected behavior: http://bugs.php.net/fix.php?id=53704&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53704&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53704&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53704&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53704&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53704&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53704&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53704&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53704&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53704&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53704&r=mysqlcfg
Bug #53695 [Opn->Asn]: Bugs are not outputed when using php-fpm
Edit report at http://bugs.php.net/bug.php?id=53695&edit=1 ID: 53695 Updated by: ka...@php.net Reported by:szoftos at freemail dot hu Summary:Bugs are not outputed when using php-fpm -Status: Open +Status: Assigned Type: Bug Package:FPM related Operating System: FreeBSD PHP Version:5.3.5 -Assigned To: +Assigned To:fat Block user comment: N Private report: N New Comment: Hmm, I wonder if php-fpm is actually parsing the error_reporting constants with their numeric bitfields to mask it correctly, could be wrong here. Any thoughts fat? Previous Comments: [2011-01-08 13:01:47] szoftos at freemail dot hu Description: Hi, when i was trying to see an error message because of a syntax error (or any other error) using php-fpm, it simply won't output. Sometimes i get nothing, and other times i get an '500 Server error'. When i use php-cli, i get the error message. my configure line (comes from freebsd ports): './configure' '--with-layout=GNU' '--localstatedir=/var' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml' '--with-libxml-dir=/usr/local' '--with-pcre-regex=/usr/local' '--with-zlib-dir=/usr' '--program-prefix=' '--enable-fpm' '--with-fpm-user=www' '--with-fpm-group=www' '--with-regex=php' '--with-zend-vm=CALL' '--enable-zend-multibyte' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' '--build=amd64-portbld-freebsd8.1' The following extensions are compiled in: [r...@wwwjail ~]# cat /var/db/ports/php5-extensions/options # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for php5-extensions-1.4 _OPTIONS_READ=php5-extensions-1.4 WITHOUT_BCMATH=true WITH_BZ2=true WITH_CALENDAR=true WITH_CTYPE=true WITHOUT_CURL=true WITHOUT_DBA=true WITH_DOM=true WITH_EXIF=true WITHOUT_FILEINFO=true WITHOUT_FILTER=true WITHOUT_FRIBIDI=true WITH_FTP=true WITH_GD=true WITH_GETTEXT=true WITH_GMP=true WITH_HASH=true WITH_ICONV=true WITH_IMAP=true WITHOUT_INTERBASE=true WITH_JSON=true WITHOUT_LDAP=true WITH_MBSTRING=true WITHOUT_MCRYPT=true WITHOUT_MSSQL=true WITH_MYSQL=true WITHOUT_MYSQLI=true WITHOUT_ODBC=true WITH_OPENSSL=true WITHOUT_PCNTL=true WITH_PDF=true WITH_PDO=true WITH_PDO_SQLITE=true WITHOUT_PGSQL=true WITH_POSIX=true WITH_PSPELL=true WITHOUT_READLINE=true WITHOUT_RECODE=true WITH_SESSION=true WITHOUT_SHMOP=true WITH_SIMPLEXML=true WITHOUT_SNMP=true WITH_SOAP=true WITHOUT_SOCKETS=true WITH_SQLITE=true WITHOUT_SYBASE_CT=true WITHOUT_SYSVMSG=true WITHOUT_SYSVSEM=true WITHOUT_SYSVSHM=true WITHOUT_TIDY=true WITH_TOKENIZER=true WITHOUT_WDDX=true WITH_XML=true WITH_XMLREADER=true WITH_XMLRPC=true WITH_XMLWRITER=true WITHOUT_XSL=true WITHOUT_YAZ=true WITH_ZIP=true WITH_ZLIB=true The related php-fpm.conf snippet is: php_admin_value[error_reporting] = "E_ALL" php_admin_flag[display_errors] = On php_admin_flag[display_startup_errors] = On Test script: --- Expected result: PHP Parse error: syntax error, unexpected T_STRING in test.php on line 3 Actual result: -- Nothing, or a '500 Internal server error' result. -- Edit this bug report at http://bugs.php.net/bug.php?id=53695&edit=1
Req #53700 [Opn->Wfx]: Correct city name
Edit report at http://bugs.php.net/bug.php?id=53700&edit=1 ID: 53700 Updated by: ahar...@php.net Reported by:bimal at sanjaal dot com Summary:Correct city name -Status: Open +Status: Wont fix Type: Feature/Change Request Package:Date/time related Operating System: all PHP Version:5.3.5 Block user comment: N Private report: N New Comment: All current stable versions of PHP include both Asia/Katmandu and Asia/Kathmandu (with both of them being identical). As I understand it, this is due to a spelling mistake in the time zone database itself that was only rectified two or three years ago; since there is likely to be old code that relies on the misspelled version of Katmandu, both names have been retained. Closing won't fix. Previous Comments: [2011-01-09 08:52:50] bimal at sanjaal dot com Description: The city name is wrong in the binary compile. 'Asia/Katmandu' => 5.45, It should be actually typed as: 'Asia/Kathmandu' => 5.45, Many other applications use the correct name: Kathmandu. May be PHP has to fix it and announce. -- Edit this bug report at http://bugs.php.net/bug.php?id=53700&edit=1
[PHP-BUG] Req #53705 [NEW]: Add AOP & Interception Filter Support
From:
Operating system: NA
PHP version: Irrelevant
Package: *Programming Data Structures
Bug Type: Feature/Change Request
Bug description:Add AOP & Interception Filter Support
Description:
I propose a modification to the PHP core adding the following features.
(Not all inclusive, I'll try to include everything I think needs to be
added).
I guess this could be called interception. The official name is AOP. What
it would enable you to do is intercept method calls immediately before and
after they are executed. It would also enable you to filter the arguments
sent to the methods.
We would need:
A way to enable this feature.
A way to add interceptions
A way to list interceptions
A way to remove interceptions
The ability to view interceptions in standard debug backtraces.
Test script:
---
interception::attachBefore('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::attachFilter('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::attachAfter('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::detachBefore('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::detachFilter('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::detachAfter('className', 'methodName', 'classToExecute',
'methodToExecute');
$list = interception::getAll();
$list = interception::getForClass('className', [methodName]);
interception::clearAll();
Expected result:
When attaching an intercept before a method call, the methodToExecute will
receive the exact same arguments as the intercepted methodName. Immediately
after methodToExecute has completed, methodName will then be executed.
When attaching an intercept filter, the methodToExecute method will receive
the exact same arguments as the intercepted methodName passed by reference
(maybe). It can then modify the arguments if required.
When attaching an intercept after a method call, the methodToExecute will
receive the exact same arguments as the intercepted methodName in addition
to the return value of methodName.
--
Edit bug report at http://bugs.php.net/bug.php?id=53705&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53705&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53705&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53705&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53705&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53705&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53705&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53705&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53705&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53705&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53705&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53705&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53705&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53705&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53705&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53705&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53705&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53705&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53705&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53705&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53705&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53705&r=mysqlcfg
Req #53705 [Opn->Wfx]: Add AOP & Interception Filter Support
Edit report at http://bugs.php.net/bug.php?id=53705&edit=1
ID: 53705
Updated by: ras...@php.net
Reported by:inbox at astions dot com
Summary:Add AOP & Interception Filter Support
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package:*Programming Data Structures
Operating System: NA
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
You could do exactly the same thing with a __call() wrapper method in
the class
assuming you are able to modify the class and make the methods provate
so they can
only be called via the __call() wrapper.
The overhead of checking every function call for before, filter and
after trigger
methods in an interpreted scripting language prevents this from being a
realistic
feature request.
Previous Comments:
[2011-01-10 07:59:26] inbox at astions dot com
Description:
I propose a modification to the PHP core adding the following features.
(Not all inclusive, I'll try to include everything I think needs to be
added).
I guess this could be called interception. The official name is AOP.
What it would enable you to do is intercept method calls immediately
before and after they are executed. It would also enable you to filter
the arguments sent to the methods.
We would need:
A way to enable this feature.
A way to add interceptions
A way to list interceptions
A way to remove interceptions
The ability to view interceptions in standard debug backtraces.
Test script:
---
interception::attachBefore('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::attachFilter('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::attachAfter('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::detachBefore('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::detachFilter('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::detachAfter('className', 'methodName', 'classToExecute',
'methodToExecute');
$list = interception::getAll();
$list = interception::getForClass('className', [methodName]);
interception::clearAll();
Expected result:
When attaching an intercept before a method call, the methodToExecute
will receive the exact same arguments as the intercepted methodName.
Immediately after methodToExecute has completed, methodName will then be
executed.
When attaching an intercept filter, the methodToExecute method will
receive the exact same arguments as the intercepted methodName passed by
reference (maybe). It can then modify the arguments if required.
When attaching an intercept after a method call, the methodToExecute
will receive the exact same arguments as the intercepted methodName in
addition to the return value of methodName.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53705&edit=1
Req #53705 [Wfx]: Add AOP & Interception Filter Support
Edit report at http://bugs.php.net/bug.php?id=53705&edit=1
ID: 53705
User updated by:inbox at astions dot com
Reported by:inbox at astions dot com
Summary:Add AOP & Interception Filter Support
Status: Wont fix
Type: Feature/Change Request
Package:*Programming Data Structures
Operating System: NA
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I believe the overhead would be negligible or non-existent because:
1. The feature could be implemented in a way where it has to be
explicitly enabled.
2. The lookups could use array keys which would be very fast and only
add a few CPU cyles to each method call.
Previous Comments:
[2011-01-10 08:05:21] ras...@php.net
You could do exactly the same thing with a __call() wrapper method in
the class
assuming you are able to modify the class and make the methods provate
so they can
only be called via the __call() wrapper.
The overhead of checking every function call for before, filter and
after trigger
methods in an interpreted scripting language prevents this from being a
realistic
feature request.
[2011-01-10 07:59:26] inbox at astions dot com
Description:
I propose a modification to the PHP core adding the following features.
(Not all inclusive, I'll try to include everything I think needs to be
added).
I guess this could be called interception. The official name is AOP.
What it would enable you to do is intercept method calls immediately
before and after they are executed. It would also enable you to filter
the arguments sent to the methods.
We would need:
A way to enable this feature.
A way to add interceptions
A way to list interceptions
A way to remove interceptions
The ability to view interceptions in standard debug backtraces.
Test script:
---
interception::attachBefore('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::attachFilter('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::attachAfter('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::detachBefore('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::detachFilter('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::detachAfter('className', 'methodName', 'classToExecute',
'methodToExecute');
$list = interception::getAll();
$list = interception::getForClass('className', [methodName]);
interception::clearAll();
Expected result:
When attaching an intercept before a method call, the methodToExecute
will receive the exact same arguments as the intercepted methodName.
Immediately after methodToExecute has completed, methodName will then be
executed.
When attaching an intercept filter, the methodToExecute method will
receive the exact same arguments as the intercepted methodName passed by
reference (maybe). It can then modify the arguments if required.
When attaching an intercept after a method call, the methodToExecute
will receive the exact same arguments as the intercepted methodName in
addition to the return value of methodName.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53705&edit=1
Bug #53695 [Com]: Bugs are not outputed when using php-fpm
Edit report at http://bugs.php.net/bug.php?id=53695&edit=1 ID: 53695 Comment by: f...@php.net Reported by:szoftos at freemail dot hu Summary:Bugs are not outputed when using php-fpm Status: Assigned Type: Bug Package:FPM related Operating System: FreeBSD PHP Version:5.3.5 Assigned To:fat Block user comment: N Private report: N New Comment: Are you sure it's related to php fpm ? Here is the content of a test file: Calling from CLI: nothing, white page Calling from FPM: the same Here is the content of another test file: Calling from CLI: Fatal error: Call to undefined function nofunc() in /html/error.php on line 1 Calling from FPM: Fatal error: Call to undefined function nofunc() in /html/error.php on line 1 The behaviour is the same with CLI or FPM. @kalle: can you reproduce the problem ? Previous Comments: [2011-01-10 01:41:19] ka...@php.net Hmm, I wonder if php-fpm is actually parsing the error_reporting constants with their numeric bitfields to mask it correctly, could be wrong here. Any thoughts fat? [2011-01-08 13:01:47] szoftos at freemail dot hu Description: Hi, when i was trying to see an error message because of a syntax error (or any other error) using php-fpm, it simply won't output. Sometimes i get nothing, and other times i get an '500 Server error'. When i use php-cli, i get the error message. my configure line (comes from freebsd ports): './configure' '--with-layout=GNU' '--localstatedir=/var' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml' '--with-libxml-dir=/usr/local' '--with-pcre-regex=/usr/local' '--with-zlib-dir=/usr' '--program-prefix=' '--enable-fpm' '--with-fpm-user=www' '--with-fpm-group=www' '--with-regex=php' '--with-zend-vm=CALL' '--enable-zend-multibyte' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' '--build=amd64-portbld-freebsd8.1' The following extensions are compiled in: [r...@wwwjail ~]# cat /var/db/ports/php5-extensions/options # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for php5-extensions-1.4 _OPTIONS_READ=php5-extensions-1.4 WITHOUT_BCMATH=true WITH_BZ2=true WITH_CALENDAR=true WITH_CTYPE=true WITHOUT_CURL=true WITHOUT_DBA=true WITH_DOM=true WITH_EXIF=true WITHOUT_FILEINFO=true WITHOUT_FILTER=true WITHOUT_FRIBIDI=true WITH_FTP=true WITH_GD=true WITH_GETTEXT=true WITH_GMP=true WITH_HASH=true WITH_ICONV=true WITH_IMAP=true WITHOUT_INTERBASE=true WITH_JSON=true WITHOUT_LDAP=true WITH_MBSTRING=true WITHOUT_MCRYPT=true WITHOUT_MSSQL=true WITH_MYSQL=true WITHOUT_MYSQLI=true WITHOUT_ODBC=true WITH_OPENSSL=true WITHOUT_PCNTL=true WITH_PDF=true WITH_PDO=true WITH_PDO_SQLITE=true WITHOUT_PGSQL=true WITH_POSIX=true WITH_PSPELL=true WITHOUT_READLINE=true WITHOUT_RECODE=true WITH_SESSION=true WITHOUT_SHMOP=true WITH_SIMPLEXML=true WITHOUT_SNMP=true WITH_SOAP=true WITHOUT_SOCKETS=true WITH_SQLITE=true WITHOUT_SYBASE_CT=true WITHOUT_SYSVMSG=true WITHOUT_SYSVSEM=true WITHOUT_SYSVSHM=true WITHOUT_TIDY=true WITH_TOKENIZER=true WITHOUT_WDDX=true WITH_XML=true WITH_XMLREADER=true WITH_XMLRPC=true WITH_XMLWRITER=true WITHOUT_XSL=true WITHOUT_YAZ=true WITH_ZIP=true WITH_ZLIB=true The related php-fpm.conf snippet is: php_admin_value[error_reporting] = "E_ALL" php_admin_flag[display_errors] = On php_admin_flag[display_startup_errors] = On Test script: --- Expected result: PHP Parse error: syntax error, unexpected T_STRING in test.php on line 3 Actual result: -- Nothing, or a '500 Internal server error' result. -- Edit this bug report at http://bugs.php.net/bug.php?id=53695&edit=1
Req #53705 [Wfx]: Add AOP & Interception Filter Support
Edit report at http://bugs.php.net/bug.php?id=53705&edit=1
ID: 53705
Updated by: ras...@php.net
Reported by:inbox at astions dot com
Summary:Add AOP & Interception Filter Support
Status: Wont fix
Type: Feature/Change Request
Package:*Programming Data Structures
Operating System: NA
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
But it is an extra lookup on every function call to check if it it
enabled which
means all existing applications will be affected. And once enabled,
every call on
the class it was enabled on would be stuck with another 3 lookups. This
is too
much damage for a feature almost noone would use.
Previous Comments:
[2011-01-10 08:08:24] inbox at astions dot com
I believe the overhead would be negligible or non-existent because:
1. The feature could be implemented in a way where it has to be
explicitly enabled.
2. The lookups could use array keys which would be very fast and only
add a few CPU cyles to each method call.
[2011-01-10 08:05:21] ras...@php.net
You could do exactly the same thing with a __call() wrapper method in
the class
assuming you are able to modify the class and make the methods provate
so they can
only be called via the __call() wrapper.
The overhead of checking every function call for before, filter and
after trigger
methods in an interpreted scripting language prevents this from being a
realistic
feature request.
[2011-01-10 07:59:26] inbox at astions dot com
Description:
I propose a modification to the PHP core adding the following features.
(Not all inclusive, I'll try to include everything I think needs to be
added).
I guess this could be called interception. The official name is AOP.
What it would enable you to do is intercept method calls immediately
before and after they are executed. It would also enable you to filter
the arguments sent to the methods.
We would need:
A way to enable this feature.
A way to add interceptions
A way to list interceptions
A way to remove interceptions
The ability to view interceptions in standard debug backtraces.
Test script:
---
interception::attachBefore('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::attachFilter('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::attachAfter('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::detachBefore('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::detachFilter('className', 'methodName', 'classToExecute',
'methodToExecute');
interception::detachAfter('className', 'methodName', 'classToExecute',
'methodToExecute');
$list = interception::getAll();
$list = interception::getForClass('className', [methodName]);
interception::clearAll();
Expected result:
When attaching an intercept before a method call, the methodToExecute
will receive the exact same arguments as the intercepted methodName.
Immediately after methodToExecute has completed, methodName will then be
executed.
When attaching an intercept filter, the methodToExecute method will
receive the exact same arguments as the intercepted methodName passed by
reference (maybe). It can then modify the arguments if required.
When attaching an intercept after a method call, the methodToExecute
will receive the exact same arguments as the intercepted methodName in
addition to the return value of methodName.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53705&edit=1
