Re: [PHP-DEV] Re: another fix for max_input_vars.

Am 04.01.2012 21:02, schrieb Rasmus Lerdorf: > But there is a very valid security concern here. People can usually run > safely with display_errors enabled if their code is well-written. if it is well written there would be nor errors displayed but you miss - in production you MUST NOT dispaly

Re: [PHP-DEV] Re: another fix for max_input_vars.

Am 04.01.2012 21:07, schrieb Paul Dragoonis: > I agree with Rasmus here. A lot of people keep display_errors on, even > when they shouldn't. it is not the job of a programming language stop admins from beeing stupid - the defaults have to be sane and this is display_error OFF, if somebody decid

Re: [PHP-DEV] FD_SETSIZE warning?

Am 13.01.2012 17:36, schrieb Rasmus Lerdorf: > FD_SETSIZE is a system limit on the number of open files a single > process can have. From a bash shell type: ulimit -n > and you will probably see this magical 1024 number pop up. This means > that the default is 1024 on your system, so raising it in

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

Am 02.02.2012 14:38, schrieb Pierre Joye: > About the current flaw affecting 5.3/4, PHP and suhosin had bugs, and > will have bugs. This is not really hot news. That does not affect this > discussion. > > I, for one, like the idea to finally see distros droping Suhosin and > focus on making PHP it

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

Am 02.02.2012 18:37, schrieb Stas Malyshev: >> yes, but suhosin-extension and hardening patch exists since many years >> >> the question from a normal user: >> why are these things not included in the core? > > Because some of these things slow down the code we are using suhosin patch and exte

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

Am 02.02.2012 19:02, schrieb Stas Malyshev: > Hi! > >> with many hundret active sessions was not a >> single performance problem > > I'm not sure I understand what you are talking about here. Performance is a > scale, > not a trigger. If you lose 10% (totally invented number as an example) th

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

Am 02.02.2012 19:42, schrieb Tomas Kuliavas: > 2012.02.02 19:42 Reindl Harald rašė: >> security is THE benefit for ALL users, especially in days where many >> are running crap-code like Joomla/Wordpress with all sorts of plugins >> throwing millions of warning if you run wi

Re: [PHP-DEV] The case of HTTP response splitting protection in PHP

Am 03.02.2012 21:44, schrieb Ángel González: >> If you or anyone else find any problem, please report a bug; otherwise >> I'll merge to 5.3 and 5.4 once 5.4 is out of code freeze. >> > As it's a security patch and of small scope, I would consider it for > 5.4. Stas, David? as it is SECURITY rele

Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from preg_replace

what he hell - if you kill eval you would kill the whole work of my life and yes i know that eval is evil and it is only used at one place which is a central and real important to include modules and set parameters dynamically the /e modifier is a total other dimension because it can be used by pe

Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from preg_replace

2012 at 11:34 AM, Reindl Harald wrote: >> what he hell - if you kill eval you would kill the whole >> work of my life and yes i know that eval is evil and >> it is only used at one place which is a central and >> real important to include modules and set parameters >> dyna

Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from preg_replace

Am 05.02.2012 17:45, schrieb Michael Stowe: > Perhaps another option, if it's a security concern is the ability > to turn off the /e modifier, and have it off by default. This way > we can protect our less experienced programmers, while keeping it > available for more advanced use cases. > >

Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from preg_replace

Am 05.02.2012 18:09, schrieb Nikita Popov: > On Sun, Feb 5, 2012 at 5:45 PM, Michael Stowe wrote: > [snip] >> Perhaps another option, if it's a security concern is the ability to turn >> off the /e modifier, and have it off by default. This way we can protect our >> less experienced programmer

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

Am 06.02.2012 16:00, schrieb Michael Morris: > Having watched this discussion unfold, I for one intend to discontinue > using Sushonin. I advise others to do the same. The character displayed by > Stefan throughout this thread speaks for itself as to why. if your make technical decisions especi

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

st the code. If I do not trust > it, I don't run it. > > On Mon, Feb 6, 2012 at 10:15 AM, Reindl Harald wrote: > >> if your make technical decisions especially security ones by >> "The character displayed by Stefan" you are maybe doing the >> wrong job!

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

Am 06.02.2012 17:10, schrieb Michael Morris: > > > On Mon, Feb 6, 2012 at 10:32 AM, Reindl Harald <mailto:h.rei...@thelounge.net>> wrote: > > first: do not top-post if you get a reply below > > second: > in the context of suhosin "w

Re: [PHP-DEV] When is PHP6 Beta going to be available ;)

Am 07.02.2012 13:39, schrieb Matti Bickel: > On 02/04/2012 09:26 PM, Lester Caine wrote: >> I'm just looking into my annual dedicated server update since it's the >> only way to get the current contract prices, and I find that ! and 1 are >> still advertising support for PHP6 Beta :) I wonder how

Re: [PHP-DEV] Security risk how to use find recommended in php.ini-*

Am 09.02.2012 00:35, schrieb Ondřej Surý: > Much better would be: > > find /path/to/sessions -cmin +24 -delete > or at least > find /path/to/sessions -cmin +24 -execdir rm "{}" \; (GNU find) > > The most error-prone way is something we cooked up in Debian: > > find /var/lib/php5/ -depth -minde

Re: [PHP-DEV] Internal server error on PHP syntax error?

Am 13.02.2012 18:08, schrieb Jakov Sosic: > and I get this in logs: > IPADDR - - [13/Feb/2012:18:03:52 +0100] "GET /~username/test/ HTTP/1.1" 500 > 20 "-" "Mozilla/5.0 (X11; Linux x86_64; > rv:10.0.1) Gecko/20100101 Firefox/10.0.1" > > so, 500 headers are returned but internal server error page

Re: [PHP-DEV] About CVE-2012-0831 (magic_quotes_gpc remote disable vulnerability?)

Am 14.02.2012 14:02, schrieb Kousuke Ebihara: > Hi, > > I've noticed the following CVE: > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0831 > >> PHP before 5.3.10 does not properly perform a temporary change to the >> magic_quotes_gpc directive during the importing of environment

Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?

Am 24.02.2012 20:57, schrieb Stas Malyshev: > Hi! > >> If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be >> included? This would reduce any negative user sentiment that "PHP 5.4 >> doesn't even support the latest Apache". > > Latest Apache is about 3 days old now :) If som

Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?

Am 25.02.2012 00:09, schrieb Bostjan Skufca: > Despite the fact that Apache HTTPD's website says that 2.4.1 "represents > the best available version of Apache HTTP Server", and that PHP 5.4.0 will > probably also bear similar notation (guesswork here!), very few (if any!) > production environment

Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache

Am 28.02.2012 22:41, schrieb Sebastian Bergmann: > On 02/28/2012 02:44 PM, Christopher Jones wrote: >> Build PHP with ZTS enabled by default. Allow it to be explicitly >> disabled during 'configure' > > Why punish everyone by default because of Apache? Does not make sense to > me. even for ap

Re: [PHP-DEV] PHP 5.4.0 released!

Am 02.03.2012 00:46, schrieb Kris Craig: > LOL tell me about it! The default PHP repos for many OSes are still using > 5.1.x so what using 5.3.x in production since 3 months after release everywhere learning to build packages for your OS is the key signature.asc Description: OpenPGP dig

Re: [PHP-DEV] '

Am 06.03.2012 01:03, schrieb Kris Craig: > I've never understood the "it's easier to read" argument since I've found > it to be exactly the opposite. The me, makes it more difficult to "at a glance" see where the PHP code begins if you hvae a usebale editor would become different colors only

Re: [PHP-DEV] '

Am 06.03.2012 01:13, schrieb Kris Craig: > On Windows (where I generally do most of my scripting grunt work), > I typically use Notepad++ and it highlights > > On Mon, Mar 5, 2012 at 4:11 PM, Reindl Harald <mailto:h.rei...@thelounge.net>> wrote: > Am 06.03.2012 0

Re: [PHP-DEV] consider reverting E_ALL with E_STRICT

Am 06.03.2012 17:08, schrieb Alan Knowles: > However with E_STRICT included we have to run around and find all the code, > and > change it to stuff like this: error_reporting(E_ALL & E_STRICT ? E_ALL ^ > E_STRICT : E_ALL); > > Could we please revert that, and if people want an all encompasing

Re: [PHP-DEV] consider reverting E_ALL with E_STRICT

Am 06.03.2012 17:22, schrieb Gustavo Lopes: > On Tue, 06 Mar 2012 17:08:07 +0100, Alan Knowles wrote: > >> [...] >> However with E_STRICT included we have to run around and find all the code, >> and change it to stuff like this: >> >> error_reporting(E_ALL & E_STRICT ? E_ALL ^ E_STRICT : E_ALL

Re: [PHP-DEV] '

Am 06.03.2012 19:36, schrieb Kris Craig: > Sorry. Sometimes I forget that there are some people out there who still > use legacy non-threaded inboxes. I would recommend you consider switching > to Gmail or some other email client/service that supports threaded views. > That will make it a lot e

Re: [PHP-DEV] consider reverting E_ALL with E_STRICT

Am 07.03.2012 01:11, schrieb Alan Knowles: > Sorry - top post as I can't reply to all the mails on the thread.. > > - display errors on. > Yes, this is a business decision, 20 servers running upgraded at different > times, some have less maintenance others > have more.. Seriously, the chance of

Re: [PHP-DEV] '

Am 07.03.2012 00:15, schrieb Kris Craig: >> In such cases, the people breaking the thread convention should >> the very least remove all the other content. >> And yes, his MUA does support threading. >> >> >> > > I'll try this one last time: I don't know what the solution is. learning to use

Re: [PHP-DEV] Quoting again

Am 07.03.2012 11:12, schrieb Pierre Joye: > On Wed, Mar 7, 2012 at 11:05 AM, Derick Rethans wrote: > >> The mailinglist guidelines also are for you, so let me repeat what I >> wrote yesterday: > > To write a one line reply to another one line reply is just fine. > > Make us all a favour, don'

Re: [PHP-DEV] Upgrade cURL extension

Am 10.03.2012 18:28, schrieb Simon Schick: > I'd like to see a new interface for curl in php ... I have no special > idea how, but I heard from several people that they pretty much don't > like the way curl is implemented in php. many other people would not like to break their perfect working co

Re: [PHP-DEV] Small question about performance

Am 15.03.2012 18:41, schrieb Paul Dragoonis: >>> I don't really know when PHP frees temporary variables, but my guess >>> was that they are freed when the scope is left. >> >> Each variable has a refcount, then that hits 0 it can be freed up. > > To add to that. A zval will have a refcount, so i

Re: [PHP-DEV] Small question about performance

thanks exactly what i assumed, but better to be sure instead wasting somewhere ressources without need :-) Am 15.03.2012 20:10, schrieb Michael Stowe: > The $b on this example would be freed as it is in the function's scope, and > not the global scope. The exception to this would be a static var

Re: [PHP-DEV] PHP5.4 'nannying'

Am 18.03.2012 10:14, schrieb Lester Caine: > I think what I am probably looking for is a clean guide as to how code SHOULD > be written nowadays in order to avoid > the nanny messages since it's certainly not my normal practice after 10 years > of coding in PHP5 ... usually it would have been

Re: [PHP-DEV] PHP5.4 'nannying'

Am 18.03.2012 18:53, schrieb Lester Caine: > Ferenc Kovacs wrote: >> * *|E_ALL|* now includes *|E_STRICT|* level errors in the error_reporting >> >> >> configuration >> directive. >> >> I would guess your

Re: [PHP-DEV] RFC: Removing PHP tags

Am 01.04.2012 03:59, schrieb Moriyoshi Koizumi: > Hi, > > I wrote a RFC that proposes removal of PHP tags. There is actually > strong public demand for it, and I also think it is necessary to > leverage PHP to a genuine, modern scripting language. > > http://wiki.php.net/rfc/nophptags nice 1s

Re: [PHP-DEV] PHP as a template language

Am 06.04.2012 04:55, schrieb Sébatien Durand: > IMHO, PHP is a great template language. This is what makes it so simple > and powerful, compared to other web languages. > > So far, we have " > A suggestion : deprecate these old tags and replace them with a more > elegant and a shorter impleme

Re: [PHP-DEV] PHP as a template language

oler short tag?". >>> The question should be "What needs to be done to make PHP an industry >>> leader in template languages again?". >>> >>> My two cents, >>> >>> John Crenshaw >>> Priacta, Inc. >>> >>> -- >>

Re: [PHP-DEV] PHP as a template language

tic. The difference relative to >>>> htmlentities(..., ENT_QUOTES | ENT_HTML5, 'UTF-8'); ?> however is 56 >>>>> characters, security, and encoding bugs. >>>>> >>>>> Proper handling of output escaping is standard in modern template &

Re: [PHP-DEV] PHP as a template language

Am 06.04.2012 23:54, schrieb Tom Boutell: > On Fri, Apr 6, 2012 at 5:39 PM, Reindl Harald wrote: >> what do you expect by propose work for many people > Oh I'm sorry, do we need to start every feature suggestion with a > description of exactly who will do the work? the &qu

Re: [PHP-DEV] PHP as a template language

Am 07.04.2012 01:30, schrieb Chris Stockton: > Hello, > > On Fri, Apr 6, 2012 at 3:08 PM, Reindl Harald wrote: >> >> >> Am 06.04.2012 23:54, schrieb Tom Boutell: >>> On Fri, Apr 6, 2012 at 5:39 PM, Reindl Harald >>> wrote: >> >> th

Re: [PHP-DEV] PHP class files without

based on mime types etc. >>> >>> This way .php continues to behave exactly as it does today, and can >>> interoperate smoothly with code that uses .phpc. .phpc can require >>> .php and vice versa. They are friends. >>> >>> Thoughts? >>> >>> -

Re: [PHP-DEV] PHP class files without

Am 07.04.2012 15:43, schrieb Stuart Dallas: > On 7 Apr 2012, at 14:39, Tom Boutell wrote: > >> From the viewpoint of someone writing reusable classes, the need to >> start with > above it is a silly annoyance they don't experience with other tools. >> >> That said, you are making valid points, I

Re: [PHP-DEV] PHP class files without

Am 07.04.2012 16:00, schrieb Tom Boutell: > That's a good point too. > > I think this is a better proposal: > > include_code, require_code, and require_code_once would work just like > include, require and require_once, except that the parser would start > out in PHP mode. would you please lea

Re: [PHP-DEV] PHP class files without

Am 07.04.2012 16:07, schrieb Derick Rethans: > On Sat, 7 Apr 2012, Reindl Harald wrote: > >> and no the world is not turning around you or even around PHP > > I will once more suggest you tune down your language on the > mailinglists. It's often rude and offens

Re: [PHP-DEV] PHP class files without

Am 07.04.2012 16:23, schrieb Tom Boutell: > On Sat, Apr 7, 2012 at 10:06 AM, Reindl Harald wrote: >> why do you simply not realize that you have way too few knowledge >> and tchnical education to partly understand the side effects >> small changes in a general behavior

[PHP-DEV] dangerous handling of security bugs

kport them by the admin So why there is no 5.3.2.1 which only fixes them? -- Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ -- PHP Inte

Re: [PHP-DEV] dangerous handling of security bugs

Am 10.07.2010 23:52, schrieb Rasmus Lerdorf: > On 7/10/10 2:32 PM, Reindl Harald wrote: >> Why there are no point releases for security-bugs? >> >> The changelog form 5.3.2 to 5.3.3 RCx shows many >> security releases which are well known in the meantime >> &

Re: [PHP-DEV] dangerous handling of security bugs

Am 11.07.2010 00:29, schrieb Rasmus Lerdorf: > On 7/10/10 3:17 PM, Reindl Harald wrote: >> What is enough on shared hosting because there are many ways >> to trigger local exploits. If there is ANY eval-injection >> in a for the admin unkown script you heave a full remot

Re: [PHP-DEV] dangerous handling of security bugs

Am 11.07.2010 00:39, schrieb Rasmus Lerdorf: > We do fix them, but we don't have the capacity to do point releases for > every local exploit fix. We simply don't have enough people to do that. > A shared host who is worried about local exploits need to take other > measures because most of the s

Re: [PHP-DEV] dangerous handling of security bugs

Am 12.07.2010 15:29, schrieb Rasmus Lerdorf: > Even for small sites, you can get your own VM from Rackspace > Cloud for about $10/month or from linode or any number of providers > where you are not sharing your PHP environment with anyone. > > -Rasmus This is no argument because the most envirnon

Re: [PHP-DEV] dangerous handling of security bugs

istros' security patches. We work with the distros > and CVEs are issued for security problems. They are the ones providing > what people like that install anyway, not us. > > -Rasmus -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, H

Re: [PHP-DEV] dangerous handling of security bugs

Am 12.07.2010 18:47, schrieb sean finney: > On Mon, Jul 12, 2010 at 03:50:19PM +0200, Reindl Harald wrote: >> It would be really relaxter if there are easy patches >> available which i could use in rpm-spec-file in a way >> like the following - the orinial source-tarbal

Re: [PHP-DEV] dangerous handling of security bugs

nt and thousand other things while the upstream-developers could include this in the automatic build or will you tell me the http://snaps.php.net/ are manually started? -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 software-development / cms-sol

Re: [PHP-DEV] dangerous handling of security bugs

the next stable release or take the patches in their own build-environment if such one exists -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546

Re: [PHP-DEV] dangerous handling of security bugs

Am 13.07.2010 11:10, schrieb Patrick ALLAERT: > 2010/7/12 Reindl Harald : >> Jesus christ I AM THE ADMIN TOO and i have no time to >> to the sysadminjob > > Congratulations, you just pinpointed the problem yourself. What do you try me to say? Other admins are not interest

Re: [PHP-DEV] dangerous handling of security bugs

Am 13.07.2010 13:40, schrieb Pierre Joye: > Did you ever run PHP RCs and reported issues? > Dong so will free us some time and helps to reduce > the time to release. I did, even with a automatic snaphsot-build-system on my homeserver But after repeatly set bugreports as "bogus" and reopening afte

Re: [PHP-DEV] dangerous handling of security bugs

Am 13.07.2010 14:29, schrieb Pierre Joye: > hi, > > On Tue, Jul 13, 2010 at 1:50 PM, Reindl Harald wrote: > >> http://bugs.php.net/bug.php?id=42836 > > The answer was clear WHAT is here clear? Someone is closing a bugreport without understanding the problem > it

Re: [PHP-DEV] dangerous handling of security bugs

> - php6 is dead as of now This was not so as i wrote the bugreport and is not related RTFM is the wrong answer to a bug, every time, every where > - open_basedir is not per directory, except if the new setting is more > - restrictive that the system one. As documented. Again what will you try m

Re: [PHP-DEV] dangerous handling of security bugs

Am 14.07.2010 06:13, schrieb Pas: > First of all, excuse me to say, but your English is horrible Maybe but does not matter > I'm also questioning your reading comprehension I'm yours too > Second of all, when you are using mod_php, then every server process > uses the same configuration Tell

Re: [PHP-DEV] dangerous handling of security bugs

Am 14.07.2010 08:58, schrieb Rasmus Lerdorf: > On 7/13/10 11:53 PM, Reindl Harald wrote: >> Sorry but if the same webserver binary is running php5 with the same vhosts >> on the same machine and only one php-version does funny things why >> does anybody start a foolish discuss

Re: [PHP-DEV] PHP 5.2.14RC3 and 5.3.3RC3 Testing

nes Schlüter > PHP 5.3 Release Master > > > -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ -- PHP I

[PHP-DEV] php-pecl-gdchart / php 5.3

http://pecl.php.net/package/GDChart Ist this extension dead or will we see a update which is compatible with php 5.3.x? -- Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq

Re: [PHP-DEV] php-pecl-gdchart / php 5.3

xtension: gd Am 19.07.2010 16:43, schrieb Rasmus Lerdorf: > On 7/19/10 5:13 AM, Reindl Harald wrote: >> >> Ist this extension dead or will we see a update >> which is compatible with php 5.3.x? > > It is dead. -- Mit besten Grüßen, Reindl Harald the lounge interactive

Re: [PHP-DEV] Remove variable function and method calls

gt; > $foo(); > new $foo(); > classname::$foo; > classname::$foo(); > > There is a word for this and that word is madness. > > The simplest is to nuke $foo(). call_user_func() is a perfect replacement. > > Regards > > Karoly Negyesi > -- Mit besten Grü

Re: [PHP-DEV] Remove variable function and method calls

Am 23.07.2010 01:36, schrieb Karoly Negyesi: >> public function __get($subclass) >> { >> $include_file = CONTENTLOUNGE_BASEDIR . 'api_' . $subclass . '.php'; >> $class_name = 'cl_' . $subclass; >> $this->$subclass = new $class_name(); >> return $this->$subclass; >> } > > And this code contai

Re: [PHP-DEV] Remove variable function and method calls

Am 23.07.2010 02:29, schrieb Karoly Negyesi: > On Thu, Jul 22, 2010 at 4:51 PM, Davey Shafik wrote: >> You can call classname::$foo() and even $obj->$foo() with call_user_func() >> should we get rid of those too? > > Absolutely not. Idiotic point of view, really there is no brain behind If you

Re: [PHP-DEV] Remove variable function and method calls

First: A personally answer is NOT "the list" Am 23.07.2010 17:27, schrieb Karoly Negyesi: >> Idiotic point of view, really there is no brain behind > > Really? so we are now down to personal attacks. Sorry but if you do not understand the first answer i have to make it clear > Now listen. *Eve

Re: [PHP-DEV] Re: Please reconsider supporting PHP 5.2

Am 25.07.2010 11:44, schrieb Karoly Negyesi: >>> Where previously the function would accept the by-value argument, a >>> fatal error is now emitted. > >> Not sure about this one. Do you have an example please? > > Erm, you do realized that I copied that from the handbook page? Example: > > func

Re: [PHP-DEV] Please reconsider supporting PHP 5.2

Am 25.07.2010 11:17, schrieb Karoly Negyesi: > This is a very interesting decision as 5.3.0, compatibility wise, is a > major release. I always felt it was PHP 6.0 but it was not called so > because there was a development branched called that (which was later > abandoned). This is simply not tr

[PHP-DEV] Karoly Negyesi: What do you really want?

I really do not understand you First you would like to see a incomatible change without any sense because you do not like some code On the other hand you are crying about the changes in 5.3 because your code which can not live with it since you ignored warnings long time ago So this sounds like

Re: [PHP-DEV] inheritance check too strict?

You can not reproduce as long your php is misconfigured error_reporting = E_ALL | E_STRICT We are using this setting on ALL our production servers to develop really clean applications Strict Standards: Declaration of ObjChild::set() should be compatible with that of ObjParent::set() in /home/harr

Re: [PHP-DEV] Named parameters

Am 15.10.2010 19:59, schrieb G M: > It's true that you can already do something similar -- although not as > easily. > I personally always use this pattern: Is it not and your sample is one of the greatest mistakes you can do * At this moment $options will be set to an empty array in the call

Re: [PHP-DEV] Named parameters

The topic are "named parameters" Am 16.10.2010 17:07, schrieb Gregory: > What ARE you talking about? > > On 10/16/10 5:55 AM, Reindl Harald wrote: >> >> Am 15.10.2010 19:59, schrieb G M: >>> It's true that you can already do something similar --

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

leads to > spaghetti programs, when used by > unexperienced users. Also they have impact on side effects from functions > that don't only rely their parameters. > > Best, > Andrey -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofm

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

Am 09.12.2010 13:46, schrieb Andrey Hristov: > There were many apps which relied on register_globals but register_globals > was introduced. > There were many apps which relied on references in PHP4, but the object model > changed in 5, references too. > There are apps which rely on magic_quotes,

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

re and clear designed and simply working since years So why in the world would you like to kill them braindead without any valid reason, and "i do not like something" is not a valid reason because nobody forces you to use such things in your scripts -- Mit besten Grüßen, Reindl H

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

Am 09.12.2010 17:49, schrieb Andrey Hristov: > sure, one's thrash is another mans cash. Stop this dumb style I know very well which script is good anough with a simple hack and where i have to do a real application style and i do not like braindead ideas forcing me to get lost this decision Ther

Re: [PHP-DEV] [PATCH] Add option to disable POST data processing

They can not configure php too or the webserver allows this for virtuals hosts (IIS afaik does) but on shared hosting this had to be done from the admin I agree that php is the wrong place If any compnent have to say "405 Method Not Allowed" it is the webserver long before starting the interprete

Re: [PHP-DEV] LXR

You have to wait unzil the TTL is over Jesus why is the TTL so hughe? lxr.php.net. 61221 IN A 94.23.222.92 [ha...@srv-rhsoft:~]$ dig A lxr.php.net @NS2.EASYDNS.COM lxr.php.net.86400 IN CNAME sp2.php.net. sp2.php.net.86400 IN A 173.236.52.218 BTW:

Re: [PHP-DEV] [RFC] Release Process

Am 03.01.2011 02:19, schrieb Enrico Weigelt: > In essence you say here, that I should diff the production config > example from one version to another to find out what changed > and adapt my config, on each update. Hm thats your job as sysadmin > Adds about 15mins extra work What is your job >

Re: [PHP-DEV] [RFC] Release Process

Am 03.01.2011 14:00, schrieb Matti Bickel: > On 01/03/2011 08:56 AM, Christian Kaps wrote: >> Since ebuild php-5.3.3 Gentoo introduced a set of new features. > > Which includes the possibility to have each minor version of PHP > installed in parallel. Sounds nice > Hence a new /etc/php layout,

Re: [PHP-DEV] implicit reference

Am 31.01.2011 21:08, schrieb Mathias Grimm: > the constraint is that all need to run on php4.3.6 and 5.3 this need does not exist since php4 died a long time ago and now it's really time that some lazy people wake up everybody who has running php4 on prodcution servers has to be fired - remembe

Re: [PHP-DEV] implicit reference

all down and waste much more time as making a branch for 5.3 with code-cleanups outside production level and update after all is done > On Tue, Feb 1, 2011 at 3:41 AM, Reindl Harald <mailto:h.rei...@thelounge.net>> wrote: > > > > Am 31.01.2011 21:08, schrieb Math

Re: [PHP-DEV] PHP for embedded device: reduce size

Am 20.02.2011 11:09, schrieb Martin Herrman: > 2011/2/20 Alexey Zakhlestin : > >> what do you mean by "remove the zend engine"? >> zend engine is the core, upon which php is built. > > Ah, that explains a lot :-) I thought zend engine is an additional > engine for performance reasons.. > > Is

Re: [PHP-DEV] PHP for embedded device: reduce size

Am 20.02.2011 15:52, schrieb Martin Herrman: > 2011/2/20 Patrick E. : > >> php-cgi 5.2.x = ~2.4mb "./configure" without : >> ... >> --without-iconv \ >> --without-pear \ >> --without-gd \ >> --disable-bcmath \ >> --disable-libxml --disable-dom --disable-simplexml --disable-xml >> --disable-xml

Re: [PHP-DEV] PHP Module unload

n PHP. > Is (fast) cgi not an option? > -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] EOL removed after ?>

Am 10.03.2011 19:30, schrieb Martin Scotta: > ok, I think I got it. > > so you think it's safe to include an empty new line after a line that ends > with ?> ? > > Martin Scotta It is a bad idea to add anything automatic There are CLI scripts out there runnign as cron-jobs and if you do this o

Re: [PHP-DEV] Adding a more logical string slicing function to PHP

Am 30.03.2011 17:54, schrieb Chad Fulton: > While I personally like PHP's substr() an awful lot > > With that in mind, if this function was to be implemented, I think > that naming it substring() instead of str_slice() might make it easier > for people to pick up out of the box, since PHP develop

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

Am 14.04.2011 12:02, schrieb Richard Quadling: > I always declare my variables. So, I don't want to use isset() as they > will be an incorrect test. I use is_null(). Specifically testing the > value. If I've made a mistake and NOT declared the variable (or made a > typo), I want to know. I don't

[PHP-DEV] PECL: "mysqlnd_ms" (Load-Balancing)

end to configured MySQL replication slave > servers > all other queries are redirected to the MySQL replication master server. Very > little, > if any, application changes required, dependent on the usage scenario > required. -- Reindl Harald the lounge interactive design

Re: [PHP-DEV] Call non-static method staticly raise E_STRICT, but why call a static method instancely won't

Am 25.04.2011 09:52, schrieb Alessandro Nadalin: >> Nothing wrong with it. >> >> The E_STRICT is raised because when you call a non-static method >> statically, $this will not be defined and that could be a problem (e.g. >> the method could rely on it). When you call a static method with ->, it >

Re: [PHP-DEV] Call non-static method staticly raise E_STRICT, but why call a static method instancely won't

Am 25.04.2011 13:17, schrieb Alessandro Nadalin: > peacefully talking, no need to be such aggressive nobody is aggressive, maybe it sounds do for you because english is not my native language and it is not always easy to make a position clear in a foreign language in the same way as in the nati

Re: [PHP-DEV] [RFC] Return type-hint

Am 28.04.2011 10:23, schrieb Stas Malyshev: > But why would I want to see these errors? > How they would make anything easier or better? to find problems before your users? i do not know what you want, but i want with "error_reporting = E_ALL | E_STRICT" get noticed if something possible is unc

Re: [PHP-DEV] adding low level file handling stuff

Am 30.04.2011 14:04, schrieb Ferenc Kovacs: > Hi. > > recently I found a nice blogpost about how to properly daemonize a php > daemon: > http://andytson.com/blog/2010/05/daemonising-a-php-cli-script-on-a-posix-system/ > I've noticed in this article, that you can replace/redirect the > STDIN/STDOU

Re: [PHP-DEV] Change Request: Make PDO default to not emulate prepared statements for MySQL

Am 30.04.2011 17:45, schrieb Ferenc Kovacs: > On Sat, Apr 30, 2011 at 5:39 PM, Rasmus Lerdorf wrote: >> Do you realize why we did this in the first place? The common versions of >> MySQL in use out there are not very clever when it comes to the native >> prepared statement handling. First, there

Re: [PHP-DEV] Change Request: Make PDO default to not emulate prepared statements for MySQL

Am 30.04.2011 20:10, schrieb Ferenc Kovacs: >> People upgrade their databases even slower than they upgrade their PHP. >> > with 5.0 EOL-ed for some time, and even the debian stable is running 5.1, I > wonder how many of our user runs 5.0. and why should anybody wait for lazy people? 5.5 did not

Re: [PHP-DEV] session_disconnect()

There is no function needed if you use http://php.net/manual/de/function.session-write-close.php like others do since ten years :-) if you know that you no longer write to the session use it this does not mean $_SESSION is lost it means only that changes to $_SESSIOn are not available for other r

Re: [PHP-DEV] session_disconnect()

Am 16.05.2011 15:50, schrieb Alain Williams: > On Mon, May 16, 2011 at 03:41:29PM +0200, Reindl Harald wrote: >> There is no function needed if you use >> http://php.net/manual/de/function.session-write-close.php >> like others do since ten years :-) > > But that

  1   2   3   >