Bug #21696 [Com]: Checkbox is strange in POST event
Edit report at https://bugs.php.net/bug.php?id=21696&edit=1
ID: 21696
Comment by: jmichae3 at yahoo dot com
Reported by:ivanpisa at dfm dot ffclrp dot usp dot br
Summary:Checkbox is strange in POST event
Status: No Feedback
Type: Bug
Package:*General Issues
Operating System: Windows 2000
PHP Version:4.3.0
Block user comment: N
Private report: N
New Comment:
browser, client side only gives the same results (somename=on for checked,
nonexistent for unchecked), even if using DHTML to access the control's
arguments from GET (examine the URL) in chrome, IE10, opera, safari (ff buggy,
checkboxes don't work for GET in ff23, submitted bug report).
my test case is my DHTML code which uses submit to .html file
http://JesusnJim.com/calculators/finances/calculator-with-estimator-to-save-up-for-item.html
try with and without checkbox checked.
I put in a w3c bug report to this effect for a change to have consistency of
operation. something may or may not change in HTML5.
Previous Comments:
[2009-05-19 04:25:40] mj at ungesundleben dot org
Same problem with PHP 5.1.4, Windows XP and Xampp 1.5.3a.
The problem is especially: How to create a CSV file from post data without
explicitely handling checkbox fields by their names if some checkbox fields
"vanish"? You will get an unusable CSV file, because the order of the fields
gets mismatched.
Workaround:
Inside the form, create checkboxes, which always are checked, but hidden for
the user (using CSS), like this:
Within a loop foreach ($_POST as $key=>$value) through the post data, you
then can do sth. like this:
if (strpos($key,"_chk")) {
if (isset($_POST[$key][1])) {$v='TRUE';} else {$v='FALSE';};
}
Regards,
Maike
[2008-09-21 11:12:33] jeff at powerupmobile dot com
Same problem with me:
Solaris 10
PHP 5.2.5
Apache 2.2.8
Seems like a simple problem to me, PHP doesn't seem to recognise when a form
checkbox is submitted with no value. I guess there are several ways to work
around it but would be nice if it recognised it like it recognises and empty
text field.
[2003-01-31 13:50:10] sni...@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2003-01-17 20:17:34] sni...@php.net
If you're really using Apache2, consider moving to Apache 1.3.27 which actually
works.
[2003-01-17 09:10:07] hholz...@php.net
are you sure that your error_reporting settings are really the same on both
boxes? (pleas check in phpinfo() output)
the message you see is only produced if E_NOTICE reporting is enabled ...
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
https://bugs.php.net/bug.php?id=21696
--
Edit this bug report at https://bugs.php.net/bug.php?id=21696&edit=1
[PHP-BUG] Req #65604 [NEW]: xmlrpc_decode return null when huge data
From: pashak at ngs dot ru Operating system: linux PHP version: 5.4.19 Package: XMLRPC-EPI related Bug Type: Feature/Change Request Bug description:xmlrpc_decode return null when huge data Description: Xml_rpc php extension uses libxml. For correct parsing huge data libxml contains a constant - LIBXML_PARSEHUGE, but I can't use it in xml_rpc extension. I can use it, for example, in simplexml extension: $res = simplexml_load_file($file, 'SimpleXMLElement', LIBXML_PARSEHUGE); Now I can't process a large file (more then 10Mb) with xmlrpc_decode as he will always return null. -- Edit bug report at https://bugs.php.net/bug.php?id=65604&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65604&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65604&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65604&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65604&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65604&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65604&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65604&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65604&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65604&r=support Expected behavior: https://bugs.php.net/fix.php?id=65604&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65604&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65604&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65604&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65604&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65604&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65604&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65604&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65604&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65604&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65604&r=mysqlcfg
Req #52583 [Com]: Improved casting and hinting, new magic method __cast()
Edit report at https://bugs.php.net/bug.php?id=52583&edit=1
ID: 52583
Comment by: thomas dot sahlin at invented dot se
Reported by:martin dot leucht at gmail dot com
Summary:Improved casting and hinting, new magic method
__cast()
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Irrelevant
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I think solution 2 would be better since that would also allow caching objects:
public static function __cast($id)
{
if (!isset(self::$cache[$id]))
self::$cache[$id] = new self($id);
return self::$cache[$id];
}
Previous Comments:
[2013-05-03 19:16:50] mkutschker-php at yahoo dot com
If we have both casting (the other one being #46128) then perhaps the names
should be __castFrom() and castTo(). Or perhaps even __castFromInt() and
castToInt() and so on.
[2012-09-05 02:53:14] ahar...@php.net
Not a dupe: request #46128 covers casting the other way. (That alone is
probably a good argument for changing the proposed magic method name.)
[2012-09-04 14:20:42] qfox at ya dot ru
dup?: https://bugs.php.net/bug.php?id=46128&thanks=6
[2010-10-19 11:41:50] rayro at gmx dot de
pretty nice, awesome feature!
but i have some recommendations on this:
1) is it true that i cannot cast to a boolean false? what about throwing the
error if no return was made? the user is able to throw some exception or will
simple not return anything to use the default error mechanism...
2) i think there should be 2 additional types of functions covering your 2
solutions by simply change the name. for your case 1 this should be __cast,
whereas 2 could be __hint? the essential difference is that __hint will be
called in the functions arguments and __cast will be called elsewhere?
[2010-10-03 18:45:29] + at ni-po dot com
@degeberg: Doesn't the RFC cover casting the other way round? I.e. Class ->
Scalar
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
https://bugs.php.net/bug.php?id=52583
--
Edit this bug report at https://bugs.php.net/bug.php?id=52583&edit=1
Bug #64010 [Com]: htmlentities fundamentally broken in 5.4
Edit report at https://bugs.php.net/bug.php?id=64010&edit=1
ID: 64010
Comment by: spam2 at rhsoft dot net
Reported by:spam2 at rhsoft dot net
Summary:htmlentities fundamentally broken in 5.4
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
and again a broken backend on a production server running E_ALL reporting
because the braindead idiot who made this change was not smart enugh to throw a
*warning* if it returs an empty string while the input was not empty
how stupid can developers act?
Previous Comments:
[2013-01-17 18:41:04] spam2 at rhsoft dot net
and last but not least WTF did whoever implemented the bullshit returning an
emptry string WITHOUT THROW A WARNING AT LEAST - who do you guys imagine that
admins/developers which are running in E_ALL | E_STRICT since years smell if
there something is still broken and need to get fixed?
[2013-01-17 13:35:36] spam2 at rhsoft dot net
and if you guys would be smart there would be an php.ini setting to specify the
bahvior globally and/or per instead hardcode incompatible changes
breaking nearly ANY code written without wrappers
[2013-01-17 13:33:21] spam2 at rhsoft dot net
as long as PHP at whole is NOT really capable UTF8 it is bullshit to assume
that any input is UTF8 as default
[2013-01-17 13:23:21] ras...@php.net
If your page is ISO-8859-1 and you are using that as your internal encoding as
well, then you need to specify that. Otherwise it leads to security issues. And
since most people don't use ISO-8859-1 anymore, the safer default is to make
sure
we don't output invalid UTF-8 byte sequences when the developer has not
specified
the encoding.
[2013-01-17 13:08:28] spam2 at rhsoft dot net
and NO it is not a smart idea to change the complete default behavior
it is bullshit, if your page is ISO-8859-1 and you do htmlentities('üöä') it
is fundamentally broken to return empty strings in a random number of funtions
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
https://bugs.php.net/bug.php?id=64010
--
Edit this bug report at https://bugs.php.net/bug.php?id=64010&edit=1
Req #41856 [Com]: support for anonymous classes
Edit report at https://bugs.php.net/bug.php?id=41856&edit=1
ID: 41856
Comment by: zatacorothx at gmail dot com
Reported by:mbaynton at gmail dot com
Summary:support for anonymous classes
Status: Open
Type: Feature/Change Request
Package:*General Issues
PHP Version:5.2.3
Block user comment: N
Private report: N
New Comment:
Anonymous classes in Java are convenient when used with Interfaces. In PHP,
this
could help with MVC frameworks. Say all pages had a class that implemented
PageController:
[some_page.php]
$page_controller = new PageInterface() {
function doGet() {}
function doPost() {}
};
A current workaround would be using a factory or constructor to which you pass
required methods, and not using an interface. It works, but then you have to
deal with missing methods in application logic where you could otherwise just
handle an error.
Previous Comments:
[2013-07-22 15:32:27] pacerier at gmail dot com
+1
[2012-03-15 18:45:47] paj...@php.net
Not exactly the same but look at closure and traits support in 5.4.
[2012-03-15 18:35:55] david71rj at gmail dot com
+1
[2011-11-09 11:34:50] antoniocs at gmail dot com
Would be nice to have this in Php 5.4 (or a latter version)
[2011-05-25 19:02:47] urkle at outoforder dot cc
David, I do not believe you are understanding the request here.
I believe this is more what is being requested.
class Base {
private $name;
public function __construct($name) {
$this->name = $name;
}
public function test() {
return $this->name;
}
}
$obj = new class extends Base {
public function test() {
return '<'.$this->name.'>';
}
};
echo $obj->test();
Basically similar to that of anonymous functions introduced in PHP 5.3
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
https://bugs.php.net/bug.php?id=41856
--
Edit this bug report at https://bugs.php.net/bug.php?id=41856&edit=1
Req #41856 [Opn]: support for anonymous classes
Edit report at https://bugs.php.net/bug.php?id=41856&edit=1
ID: 41856
Updated by: johan...@php.net
Reported by:mbaynton at gmail dot com
Summary:support for anonymous classes
Status: Open
Type: Feature/Change Request
Package:*General Issues
PHP Version:5.2.3
Block user comment: N
Private report: N
New Comment:
My guess is that anonymous classes would have a good chance once a good
implementation comes by. This is not completely trivial as the class_entry has
to be stored in the class_table but has to be somewhat hidden and we might have
to find a way to hide the information in the oparray.
As all things in PHP this needs a volunteer to do it. All contributors have
sometime X to work on PHP and in time X can either discuss stuff, fix bugs or
implement features ... but with some guidance this might be a nice project for
a newcomer (I'd volunteer to give a hand to point in the right direction etc.,
while this guarantees acceptance in no way as that would need an RFC etc.)
until then we have to live with workarounds.
For the PageController interface example an (work-around) alternative is
$page_controller = [
'get' => function () {},
'post' => function () {}
};
Previous Comments:
[2013-09-02 21:42:36] zatacorothx at gmail dot com
Anonymous classes in Java are convenient when used with Interfaces. In PHP,
this
could help with MVC frameworks. Say all pages had a class that implemented
PageController:
[some_page.php]
$page_controller = new PageInterface() {
function doGet() {}
function doPost() {}
};
A current workaround would be using a factory or constructor to which you pass
required methods, and not using an interface. It works, but then you have to
deal with missing methods in application logic where you could otherwise just
handle an error.
[2013-07-22 15:32:27] pacerier at gmail dot com
+1
[2012-03-15 18:45:47] paj...@php.net
Not exactly the same but look at closure and traits support in 5.4.
[2012-03-15 18:35:55] david71rj at gmail dot com
+1
[2011-11-09 11:34:50] antoniocs at gmail dot com
Would be nice to have this in Php 5.4 (or a latter version)
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
https://bugs.php.net/bug.php?id=41856
--
Edit this bug report at https://bugs.php.net/bug.php?id=41856&edit=1
[PHP-BUG] Bug #65607 [NEW]: Configure text change request: "Error cannot find pspell" to ".. aspell"
From: mail at tgries dot de Operating system: Linux PHP version: 5.5.3 Package: *General Issues Bug Type: Bug Bug description:Configure text change request: "Error cannot find pspell" to ".. aspell" Description: During ./configure Configure: Error cannot find pspell pspell is called aspell on OpenSuse, and perhaps on all systems. I suggest to change the text which informs about the missing component from "Cannot find pspell" to "Cannot find aspell" or "Cannot find apspell respectively pspell" -- Edit bug report at https://bugs.php.net/bug.php?id=65607&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65607&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65607&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65607&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65607&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65607&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65607&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65607&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65607&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65607&r=support Expected behavior: https://bugs.php.net/fix.php?id=65607&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65607&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65607&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65607&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65607&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65607&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65607&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65607&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65607&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65607&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65607&r=mysqlcfg
