Re: [PHP-DEV] RFC: ext/mysql deprecation
On 11/15/2012 11:27 PM, Pierre Joye wrote: hi Anthony, On Thu, Nov 15, 2012 at 9:11 PM, Anthony Ferrara ircmax...@gmail.com wrote: Actually, no it wouldn't. You still get the overhead of the error, plus any custom error handlers will be triggered regardless of the error_reporting setting which depending on the implementation of the error handler can be quite costly performance-wise. So what solution is there to this? Should it not be deprecated? This same issue (is still happening) with register_globals for us, but it's acceptable as it has been phased out. Should there be no deprecation warning now and wait for a future release? That's my suggestion. Officially deprecate it, but don't add E_DEPRECATED to it in 5.5. Update the documentation, and start a PR campaign to get off it. Then in NEXT add E_DEPRECATED and in NEXT+1 remove it. This does not make sense, at all. We introduce this flag and used it already a lot in many parts of PHP (engine included) for this exact purpose. Most major apps have mysqli support or provide working solutions to support mysqli, incl. for plugins (like wordpress, which is likely to support mysqli in Q2 2013). Not adding the E_DEPRECATED flag would be a mistake and will only add more confusions by the time we will move it out. Actually we have never used E_DEPRECATED to deprecate an entire extension. We have deprecated specific functions and engine features, but for entire extensions we have provided alternatives and/or waited for them to become inconsequential and then moved them to pecl. But we certainly never littered the extension with warnings before moving it out. How do you see adding E_DEPRECATED working here? Do we add it to every function in the extension? Just to some? And then when we move the extension to pecl do we pull the warnings back out? Surely it makes no sense to move an extension out of core to pecl and spew E_DEPRECATED warnings to people who explicitly choose to install it. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Rasmus, As per the RFC: adding E_DEPRECATED only in mysql_connect(), mysql_pconnect(). Which means only one error (normally) by request. 2012/11/16 Rasmus Lerdorf ras...@lerdorf.com: On 11/15/2012 11:27 PM, Pierre Joye wrote: hi Anthony, On Thu, Nov 15, 2012 at 9:11 PM, Anthony Ferrara ircmax...@gmail.com wrote: Actually, no it wouldn't. You still get the overhead of the error, plus any custom error handlers will be triggered regardless of the error_reporting setting which depending on the implementation of the error handler can be quite costly performance-wise. So what solution is there to this? Should it not be deprecated? This same issue (is still happening) with register_globals for us, but it's acceptable as it has been phased out. Should there be no deprecation warning now and wait for a future release? That's my suggestion. Officially deprecate it, but don't add E_DEPRECATED to it in 5.5. Update the documentation, and start a PR campaign to get off it. Then in NEXT add E_DEPRECATED and in NEXT+1 remove it. This does not make sense, at all. We introduce this flag and used it already a lot in many parts of PHP (engine included) for this exact purpose. Most major apps have mysqli support or provide working solutions to support mysqli, incl. for plugins (like wordpress, which is likely to support mysqli in Q2 2013). Not adding the E_DEPRECATED flag would be a mistake and will only add more confusions by the time we will move it out. Actually we have never used E_DEPRECATED to deprecate an entire extension. We have deprecated specific functions and engine features, but for entire extensions we have provided alternatives and/or waited for them to become inconsequential and then moved them to pecl. But we certainly never littered the extension with warnings before moving it out. How do you see adding E_DEPRECATED working here? Do we add it to every function in the extension? Just to some? And then when we move the extension to pecl do we pull the warnings back out? Surely it makes no sense to move an extension out of core to pecl and spew E_DEPRECATED warnings to people who explicitly choose to install it. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 11/16/2012 12:51 AM, Patrick ALLAERT wrote: Rasmus, As per the RFC: adding E_DEPRECATED only in mysql_connect(), mysql_pconnect(). Which means only one error (normally) by request. I still don't see the point of using E_DEPRECATED like this for an entire extension. And I think it will hurt more than it will help for an extension this heavily used. It is going to encourage people to simply turn off that warning because they will get it on every single request which means they will never see the more subtle and granular E_DEPRECATED warnings from other parts of their code. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Actually we have never used E_DEPRECATED to deprecate an entire extension. We have deprecated specific functions and engine features, but for entire extensions we have provided alternatives and/or waited for them to become inconsequential and then moved them to pecl. But we certainly never littered the extension with warnings before moving it out. How do you see adding E_DEPRECATED working here? Do we add it to every function in the extension? Just to some? And then when we move the extension to pecl do we pull the warnings back out? Surely it makes no sense to move an extension out of core to pecl and spew E_DEPRECATED warnings to people who explicitly choose to install it. -Rasmus Would it work to somehow have a pecl extension override the core-shipped extension? mysql did this when they allowed an external implementation of InnoDB to replace the InnoDB shipped with the product. This would allow turning off mysql deprecation warnings for those who know what they are doing and provide a migration path. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] RFC: ext/mysql deprecation
hi Rasmus, On Fri, Nov 16, 2012 at 9:36 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 11/15/2012 11:27 PM, Pierre Joye wrote: hi Anthony, On Thu, Nov 15, 2012 at 9:11 PM, Anthony Ferrara ircmax...@gmail.com wrote: Actually, no it wouldn't. You still get the overhead of the error, plus any custom error handlers will be triggered regardless of the error_reporting setting which depending on the implementation of the error handler can be quite costly performance-wise. So what solution is there to this? Should it not be deprecated? This same issue (is still happening) with register_globals for us, but it's acceptable as it has been phased out. Should there be no deprecation warning now and wait for a future release? That's my suggestion. Officially deprecate it, but don't add E_DEPRECATED to it in 5.5. Update the documentation, and start a PR campaign to get off it. Then in NEXT add E_DEPRECATED and in NEXT+1 remove it. This does not make sense, at all. We introduce this flag and used it already a lot in many parts of PHP (engine included) for this exact purpose. Most major apps have mysqli support or provide working solutions to support mysqli, incl. for plugins (like wordpress, which is likely to support mysqli in Q2 2013). Not adding the E_DEPRECATED flag would be a mistake and will only add more confusions by the time we will move it out. Actually we have never used E_DEPRECATED to deprecate an entire extension. We have deprecated specific functions and engine features, but for entire extensions we have provided alternatives and/or waited for them to become inconsequential and then moved them to pecl. But we certainly never littered the extension with warnings before moving it out. How do you see adding E_DEPRECATED working here? Do we add it to every function in the extension? Just to some? And then when we move the extension to pecl do we pull the warnings back out? Surely it makes no sense to move an extension out of core to pecl and spew E_DEPRECATED warnings to people who explicitly choose to install it. I see a couple of options: 1. On extension load Useful for ISPs so they will see it by updating PHP 2. On extension load and on connect Useful for users and ISPs 3. All functions Performance impact, but I do not have a problem with that. If someone worries about performance, he should have moved to mysqli already since long. About the (later) move to PECL, the installer shows superseded warnings. Sadly it is not shown by distros tools but we can't cover all cases anyway. If we go with option 1 or 2, I would keep the warning in place as well. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Nov 16, 2012, at 12:55 AM, Rasmus Lerdorf wrote: On 11/16/2012 12:51 AM, Patrick ALLAERT wrote: Rasmus, As per the RFC: adding E_DEPRECATED only in mysql_connect(), mysql_pconnect(). Which means only one error (normally) by request. I still don't see the point of using E_DEPRECATED like this for an entire extension. And I think it will hurt more than it will help for an extension this heavily used. It is going to encourage people to simply turn off that warning because they will get it on every single request which means they will never see the more subtle and granular E_DEPRECATED warnings from other parts of their code. Most front page google results for E_DEPRECATED are questions about how to hide these errors. This thought has put me over the edge and into the land of not having E_DEPRECATED for ext/mysql in 5.5. Let us prepare for this first as we are not ready. Seriously, we are not ready. And it makes me wonder about E_DEPRECATED as a whole. But this seriously makes me wonder if we should add something like how_do_i_make_my_code_more_awesome(). That may look insane (well, the function name is) but imagine it saying Stop using ext/mysql and then users hear about this, run it, and ask Wordpress Dude, this would be more awesome without ext/mysql and so on. Brainstorming. :) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
hi Philip, On Fri, Nov 16, 2012 at 10:25 AM, Philip Olson phi...@roshambo.org wrote: But this seriously makes me wonder if we should add something like how_do_i_make_my_code_more_awesome(). That may look insane (well, the function name is) but imagine it saying Stop using ext/mysql and then users hear about this, run it, and ask Wordpress Dude, this would be more awesome without ext/mysql and so on. Brainstorming. :) Wordpress lead developer statement is rather clear: Go ahead, we will follow. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Pierre Joye wrote: Wordpress lead developer statement is rather clear: Go ahead, we will follow. Indeed, we have patches written already [1], but they were low priority. The plan is to aim for landing these in the next major version, assuming PHP does go ahead with this. [1]: http://core.trac.wordpress.org/ticket/21663 -- Ryan McCue http://ryanmccue.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Hello internals. Sometimes I wonder if people even read the stuff that is written here. I understand that this thread got long, but it's not that bad - most messages are short and readable, easy to follow. As with APOCALYPSE WILL HAPPEN style claims, that we see here, I just don't understand your reasoning people. People said repeatedly, and RFC too, that it's not going to be E_DEPRECATED on every function call in the extension - it's only on mysql_connect mysql_pconnect. And seriously, guys, there are other places that throw E_WARNING, E_STIRICT and E_DEPRECATED - ignoring those is a bad idea no matter how you put it . E_DEPRECATED sends a clear message, that everyone understands. And docs are not a best place for a warning of that kind - I now look into the docs a few times a year for something specific, I just don't need to cause even I just remember the stuff I use. And IDE helps to remember the things I forgot on the fly. If I would not read this list I would know about the deprecation when I would update my developer PHP to new release and get E_DEPRECATED on my developer machine (I moved to mysqli like ages ago and frameworks make me use PDO). That's just how a regular developer works - this is an extension that like 100% of us (the guys that work with MySQL for any time longer than half a year) know by heart, why da hell do I need to read docs for that? Deprecating stuff isn't a viral video or a funny picture that gets spread virally. Yes, people write blogs, spread the word, but it's effect is far from what you want and need. I don't see how removing a whole extension is any kind of special case. You deprecate it, give people a year or so to do something about it and move the extension to PECL. It's not like you are just killing it without any options to enable it. It is always painful to remove the stuff many people use, but you just can't make it without someone realizing that stuff was deprecated like 5 years ago, removed 4 years ago and he just installed that old new version straight to the production server and it all just died. You should know better how many idiots are out there in the wild, who never learn from their mistakes. Even I make some repeated mistakes from time to time, although I try to learn my lesson - stuff just happens. Just handle it with as much noise coverage as you can - make an official statement on php.net, get attention of *nix distros and framework/cms/cmf developers, remind people on the conferences, blogs, etc. Include reasoning why are you doing this, provide migration article in the docs (like oracle's one). I never wanted to say it would be easy, but it wasn't easy to remove register_global, magic_quotes and other stuff (and it was written in this thread that Wordpress still has emulation code for this). Just prepare for it. 3-5 years should suffice for people to move to mysqli their projects, that's the time frame majority of people will just start to use versions after PHP 5.4 Arvids.
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Nov 15, 2012, at 22:28, Will Fitch wfi...@meetme.com wrote: Your argument is valid. The question of, why do we deprecate something that is so heavily used comes to mind, but in the end, this is a something the extension maintainers want - not end users. Maybe the correct solution is to hand off the maintenance of this extension to a new team? Your argument is valid. The question of, why do we deprecate something that is so heavily used comes to mind, but in the end, this is a something the extension maintainers want - not end users. Maybe the correct solution is to hand off the maintenance of this extension to a new team? There isn't much maintenance needed. For a few years already ext/mysql isn't receiving new features and bug inflow is low. Thanks to mysqlnd we have to fear libmysql changes way less these days. We, from the MySQL Connector Team at Oracle, add new features to mysqli (and eventually PDO) only, though, for quite some time already. Bugs in ext/mysql are being fixed in a best effort way and we plan to do this as long as required by the community. Users should use mysqli for having access to everything MySQL has to offer. Officially deprecating mysqli is, in my opinion, mostly a help for users to go in the correct direction early instead of struggling due to missing features later. johannes -- Johannes Schlüter, MySQL Connectors Team, ORACLE Corporation Note: The above is no legally binding promise by Oracle. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Nov 16, 2012, at 5:48, Levi Morrison morrison.l...@gmail.com wrote: I believe we haven't taken all the proper steps. Have we spent efforts educating the community? Yes. Are those efforts proportionate to the magnitude of the usage? No; ext/mysql has widespread adoption and needs widespread education and training resources. I'm happy to learn about proposals for doing that better. For years I'm preaching this at conference sessions, webinars, blog posts, private discussions, ... As do others, both from MySQL/Oracle as well as the community. I'm also happy to talk to projects etc. and assist them with migration as much as I can. johannes -- Johannes Schlüter, MySQL Connectors Team, ORACLE Corporation -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Nov 16, 2012, at 3:16, David Muir davidkm...@gmail.com wrote: The point is, an extension should never be throwing deprecation warnings for a planned migration to PECL. We should warn, when we can. There is a reason that we have PHP_DEP_FE in the source as a feature to mark functions deprecated. (99% of all functions are in extensions) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
2012/11/12 Adam Harvey ahar...@php.net: Hi everyone, I've written an RFC to cover deprecating ext/mysql in PHP 5.5: https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft deprecation in the documentation purely via a straw poll on Internals, I presume this will end up needing to go to a vote, hence the RFC. I won't rehash the background overly (there's some more detail in the RFC), other than to note that we've now had deprecation notices on all mysql_* functions in the manual for about six months and that the logical next step is to start generating E_DEPRECATED notices when users connect via mysql_connect(), mysql_pconnect() or the implicit ext/mysql connection routines. It's my belief that doing so will hasten the move of users to the more modern (and supported) APIs available: mysqli and PDO, and that this process will also likely encourage some users to switch to safer patterns such as prepared queries at the same time. I must apologise for the lateness of this RFC: I had hoped to do this some time before alpha 1, but travel and illness have taken their toll. Better late than never! So, please provide comments, feedback, concerns, and so on. Obviously, this isn't going to a vote for at least a couple of weeks, but earlier feedback is better. Thanks, Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Adam, Maybe it is worth mentioning in the RFC what the E_DEPRECATED notice message would look like so that people hiding it know what the plan is. e.g.: mysql_*() functions are, as of PHP 5.5, deprecated and will be removed in next major release. Use the mysqli_*() functions instead. Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: mysql_escape() issue (Was: [PHP-DEV] RFC: ext/mysql deprecation)
2012/11/12 Adam Harvey ahar...@php.net: Hi everyone, I've written an RFC to cover deprecating ext/mysql in PHP 5.5: https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft deprecation in the documentation purely via a straw poll on Internals, I presume this will end up needing to go to a vote, hence the RFC. I won't rehash the background overly (there's some more detail in the RFC), other than to note that we've now had deprecation notices on all mysql_* functions in the manual for about six months and that the logical next step is to start generating E_DEPRECATED notices when users connect via mysql_connect(), mysql_pconnect() or the implicit ext/mysql connection routines. It's my belief that doing so will hasten the move of users to the more modern (and supported) APIs available: mysqli and PDO, and that this process will also likely encourage some users to switch to safer patterns such as prepared queries at the same time. I must apologise for the lateness of this RFC: I had hoped to do this some time before alpha 1, but travel and illness have taken their toll. Better late than never! So, please provide comments, feedback, concerns, and so on. Obviously, this isn't going to a vote for at least a couple of weeks, but earlier feedback is better. Thanks, Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php There is one remaining issue if ext/mysql is being deprecated (only by having E_DEPRECATED in mysql_connect()/mysql_pconnect() and then removed later. People using mysql_escape() only to generate SQL files would never see the deprecation and the function would suddenly be removed. Technically, this could be solved by setting a global flag that is reset at RINIT while all mysql_* functions would emit the E_DEPRECATED notice if the global flag is not yet set (a singleton like pattern). While this is technically possible, we should still cover the following use case: make it possible to generate valid queries while not being able to connect to any MySQL server yet. In eZ Publish CMS, we have recently removed [1] support for the mysql handler in favour of the mysqli one and as such, we have no more mysql_*() functions calls except for the above use case where we rely on mysql_escape(). Opinions ? [1] https://github.com/ezsystems/ezpublish/compare/e00a2c5cfef6776e0b8d8a330b1f6cb397b1ec0e~...485c7054e2f6a381f6f562797e6d0c1cce2c59f2 Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where did the _logo_ functions go?
On Fri, Nov 16, 2012 at 3:31 AM, Sherif Ramadan theanomaly...@gmail.comwrote: On Thu, Nov 15, 2012 at 8:26 PM, Philip Olson phi...@roshambo.org wrote: Hello geeks, Why does PHP 5.5 remove the *_logo_* functions? Is this a security related move? Shouldn't these emit E_DEPRECATED errors in 5.5? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Because the guids were removed. They were replaced with data URIs. It would make sense if there was some function to expose those data URIs to user-land, in the same way that the *_guid functions did, but I guess there isn't. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php it was removed when https://github.com/php/php-src/pull/132 got merged after a brief vote on the internals mailing list. see Stas concerns about reusing the same function names for getting the data urls: http://www.mail-archive.com/internals@lists.php.net/msg59293.html -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] RFC: ext/mysql deprecation
Officially deprecating mysqli is, in my opinion, mostly a help for users to go in the correct direction early instead of struggling due to missing features later. I suppose the mysqli here was just a typo. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 16/11/2012 08:55, Rasmus Lerdorf wrote: I still don't see the point of using E_DEPRECATED like this for an entire extension. And I think it will hurt more than it will help for an extension this heavily used. It is going to encourage people to simply turn off that warning because they will get it on every single request which means they will never see the more subtle and granular E_DEPRECATED warnings from other parts of their code. Catch 22 - if you do nothing people will keep using it, even for new stuff and progress is never made. This sort of thing is obviously a horendous nightmare - I personally wonder if flat out shiping it to PECL with a warning on the PECL page but no E_DEPRECATED might be the better solution. At least then people who are installing it will be actively aware they're doing it, without the 'scary' errors spat out when they connect to a server. Anybody who needs this will ask their host for it or more likely their host will already have it installed, but people installing PHP for local dev machines will probably have to go find it (and the developers are the target audience for these sorts of things) - which should be enough to tell them there's something different about this extension, and they'll see the notice on the site. I honestly can't see a situation where that would bother people more than keeping it but throwing E_DEPRECATED fairly often with a view to moving it later anyway - rip the plaster off in one go so to speak. Maybe PHP has a lot of users that are somewhat unstable and incapable of using PECL, I dunno ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 11/16/2012 01:34 AM, Ryan McCue wrote: Pierre Joye wrote: Wordpress lead developer statement is rather clear: Go ahead, we will follow. Indeed, we have patches written already [1], but they were low priority. The plan is to aim for landing these in the next major version, assuming PHP does go ahead with this. [1]: http://core.trac.wordpress.org/ticket/21663 So, I am curious, why are you waiting on us for this? Is it because ext/mysql does everything you need and you simply have no need for any of the new and obviously better features in mysqli? I would have thought you would have switched to mysqli years ago if it was available and only used ext/mysql as a desperation fallback if that was all that was available. Not a criticism, but a curiosity. This is part of why this is going to be a very painful process no matter which path we take. It is an extension which works just fine and will continue to work for people. I wish we could come up with a better carrot for getting people to migrate versus just hitting them with a stick which most people here seem to advocate. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mysql_escape() issue (Was: [PHP-DEV] RFC: ext/mysql deprecation)
On 11/16/2012 02:18 AM, Patrick ALLAERT wrote: In eZ Publish CMS, we have recently removed [1] support for the mysql handler in favour of the mysqli one and as such, we have no more mysql_*() functions calls except for the above use case where we rely on mysql_escape(). I suppose you mean mysql_real_escape_string() here. There is no mysql_escape() function and mysql_escape_string() is already marked as deprecated as of 5.3. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mysql_escape() issue (Was: [PHP-DEV] RFC: ext/mysql deprecation)
2012/11/16 Rasmus Lerdorf ras...@lerdorf.com: On 11/16/2012 02:18 AM, Patrick ALLAERT wrote: In eZ Publish CMS, we have recently removed [1] support for the mysql handler in favour of the mysqli one and as such, we have no more mysql_*() functions calls except for the above use case where we rely on mysql_escape(). I suppose you mean mysql_real_escape_string() here. There is no mysql_escape() function and mysql_escape_string() is already marked as deprecated as of 5.3. -Rasmus Sorry, I meant mysql_escape_string(). I missed the fact it was already deprecated and as such, we have an issue here in our code base since nor mysql_real_escape_string() nor mysqli_real_escape_string() fits our use case as we are using it when we have to generate an SQL file with queries to be executed on another box. Not having access to a database prevents us to have a link which is required by those functions. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mysql_escape() issue (Was: [PHP-DEV] RFC: ext/mysql deprecation)
On 11/16/2012 09:32 AM, Patrick ALLAERT wrote: 2012/11/16 Rasmus Lerdorf ras...@lerdorf.com: On 11/16/2012 02:18 AM, Patrick ALLAERT wrote: In eZ Publish CMS, we have recently removed [1] support for the mysql handler in favour of the mysqli one and as such, we have no more mysql_*() functions calls except for the above use case where we rely on mysql_escape(). I suppose you mean mysql_real_escape_string() here. There is no mysql_escape() function and mysql_escape_string() is already marked as deprecated as of 5.3. -Rasmus Sorry, I meant mysql_escape_string(). I missed the fact it was already deprecated and as such, we have an issue here in our code base since nor mysql_real_escape_string() nor mysqli_real_escape_string() fits our use case as we are using it when we have to generate an SQL file with queries to be executed on another box. Not having access to a database prevents us to have a link which is required by those functions. But without a link you don't know which charset the db is in and therefore you can't reliably escape a query. In your case you can do a custom escape thing based on the fact that you might know the destination charset, but PHP on its own can't. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mysql_escape() issue (Was: [PHP-DEV] RFC: ext/mysql deprecation)
2012/11/16 Rasmus Lerdorf ras...@lerdorf.com: On 11/16/2012 09:32 AM, Patrick ALLAERT wrote: 2012/11/16 Rasmus Lerdorf ras...@lerdorf.com: On 11/16/2012 02:18 AM, Patrick ALLAERT wrote: In eZ Publish CMS, we have recently removed [1] support for the mysql handler in favour of the mysqli one and as such, we have no more mysql_*() functions calls except for the above use case where we rely on mysql_escape(). I suppose you mean mysql_real_escape_string() here. There is no mysql_escape() function and mysql_escape_string() is already marked as deprecated as of 5.3. -Rasmus Sorry, I meant mysql_escape_string(). I missed the fact it was already deprecated and as such, we have an issue here in our code base since nor mysql_real_escape_string() nor mysqli_real_escape_string() fits our use case as we are using it when we have to generate an SQL file with queries to be executed on another box. Not having access to a database prevents us to have a link which is required by those functions. But without a link you don't know which charset the db is in and therefore you can't reliably escape a query. In your case you can do a custom escape thing based on the fact that you might know the destination charset, but PHP on its own can't. We are defining the charset used at the beginning of the generated file and wish it could be possible to pass the charset rather than a link which is what is really needed. Looks like a valid feature request to me. Would make sense only for the procedural call of course. The first argument could then be a resource or a string. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 11/15/12 3:11 PM, Anthony Ferrara wrote: That's my suggestion. Officially deprecate it, but don't add E_DEPRECATED to it in 5.5. Update the documentation, and start a PR campaign to get off This may be a narrow PR channel, but I'd focus on getting @deprecated into the built-in function stubs in all the IDEs. In PhpStorm I see lines through the function name, and there's a deprecation section in the Inspect Code report. I'm much more likely to notice those than notice changes in online docs or error log notices. But more importantly, anyone writing *new* code will see that feedback immediately. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Thu, Nov 15, 2012 at 10:38 PM, Johannes Schlüter johannes.schlue...@oracle.com wrote: We, from the MySQL Connector Team at Oracle, add new features to mysqli (and eventually PDO) only, though, for quite some time already. Bugs in ext/mysql are being fixed in a best effort way and we plan to do this as long as required by the community. Users should use mysqli for having access to everything MySQL has to offer. Officially deprecating mysqli is, in my opinion, mostly a help for users to go in the correct direction early instead of struggling due to missing features later. Er, mysqli, too? What? -Ronabop -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Rasmus Lerdorf wrote: We need a frontpage notice. A big notice in the next UPGRADING file. There was nothing about this in the 5.4 UPGRADING file, for example. We also need tutorials showing how to migrate from mysql to mysqli and conference talks on the same showing some of the cooler things like async queries that you get by moving to a more modern API. This sounds like a much more realistic approach to the problem. The only way that E_DEPRECATED would work practically is if it was a separate E_MYSQL_EOL since there are other more important warnings that would be hidden simply to maintain mysql? But it's not just migration tutorials that are lacking, we STILL need some good quality PHP5.4 style guides! Showing how to migrate from pre PHP5.2 style working ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
I'm already working somewhat with the PhpStorm guys on other things relating to PHP. I could spearhead that effort, but I won't bring it up until this is decided. On Fri, Nov 16, 2012 at 10:53 AM, Steve Clay st...@mrclay.org wrote: On 11/15/12 3:11 PM, Anthony Ferrara wrote: That's my suggestion. Officially deprecate it, but don't add E_DEPRECATED to it in 5.5. Update the documentation, and start a PR campaign to get off This may be a narrow PR channel, but I'd focus on getting @deprecated into the built-in function stubs in all the IDEs. In PhpStorm I see lines through the function name, and there's a deprecation section in the Inspect Code report. I'm much more likely to notice those than notice changes in online docs or error log notices. But more importantly, anyone writing *new* code will see that feedback immediately. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Steve Clay wrote: On 11/15/12 3:11 PM, Anthony Ferrara wrote: That's my suggestion. Officially deprecate it, but don't add E_DEPRECATED to it in 5.5. Update the documentation, and start a PR campaign to get off This may be a narrow PR channel, but I'd focus on getting @deprecated into the built-in function stubs in all the IDEs. In PhpStorm I see lines through the function name, and there's a deprecation section in the Inspect Code report. I'm much more likely to notice those than notice changes in online docs or error log notices. But more importantly, anyone writing *new* code will see that feedback immediately. The same should work with Eclipse and PDT or PHPEclipse. If the documentation is suitably marked then any usage will flag up the situation ... educate rather than penalise? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Problem with php_value open_basedir and apache containers
I have just run into this, there is a much earlier similar issue in Apache bugzilla where they refer the problem php: https://issues.apache.org/bugzilla/show_bug.cgi?id=24120 In the apache config file I have the something like the following in a virtual host definition: php_value open_basedir /var/www/InternalFacing/:/usr/share/pear:/usr/local/php Directory /var/www/InternalFacing/html/MyHidden php_value open_basedir /var/www/InternalFacing/:/usr/share/pear:/usr/local/php:/var/somewhere/ /Directory A php script inside /var/www/InternalFacing/html/MyHidden cannot open files under /var/somewhere/. If I comment out the first 'php_value' (ie outside the Directory container) it works ... but not if I leave it in. So: it seems that 'php_value open_basedir' does not interact properly with apache containers. I am using httpd 2.2.15 and php 5.3.3 on a Centos 6 system. Regards -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Sherif Ramadan in php.internals (Thu, 15 Nov 2012 21:23:48 -0500): People have been talking about and educating others about the deprecation of ext/mysql for quite some time now. I'm sure that it could be more clearly voiced from an official PHP Project stand-point, but we're down-playing the amount of education that has already gone underway here. Nevertheless, I had only a faint idea it was going to be deprecated. I hardly ever look at the manual for the mysql_ functions because they haven't changed for years. Re-using existing code just works. I think you are overestimating the effect of those talks. My PHP-usage: legacy code without any framework, drupal6, drupal7 and regularly compiling PHP 5.3 5.4 for Win32 and Win64, mainly because I need php_ffmpeg.dll to work in those PHP versions. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where did the _logo_ functions go?
On Fri, Nov 16, 2012 at 6:10 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Fri, Nov 16, 2012 at 3:31 AM, Sherif Ramadan theanomaly...@gmail.com wrote: On Thu, Nov 15, 2012 at 8:26 PM, Philip Olson phi...@roshambo.org wrote: Hello geeks, Why does PHP 5.5 remove the *_logo_* functions? Is this a security related move? Shouldn't these emit E_DEPRECATED errors in 5.5? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Because the guids were removed. They were replaced with data URIs. It would make sense if there was some function to expose those data URIs to user-land, in the same way that the *_guid functions did, but I guess there isn't. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php it was removed when https://github.com/php/php-src/pull/132 got merged after a brief vote on the internals mailing list. see Stas concerns about reusing the same function names for getting the data urls: http://www.mail-archive.com/internals@lists.php.net/msg59293.html -- Ferenc Kovács @Tyr43l - http://tyrael.hu Obviously it doesn't make sense to use the same function names for the data uris, but why weren't new functions added to expose the data uris to userspace in the same way we used to expose the guids to userspace? It only seems to make sense that we'd continue to do that and it's such a simple fix to replace the functions with new ones. I honestly don't care too much about this particular feature myself, but it sounds pretty silly that this PR did not include the new functions for exposing the uris. My 0.2 cents... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Nov 16, 2012, at 19:06, Ronald Chmara rona...@gmail.com wrote: Er, mysqli, too? What? As Ferenc noted: This was a typo. Sorry for the confusion. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Fri, Nov 16, 2012 at 2:47 PM, Jan Ehrhardt php...@ehrhardt.nl wrote: Sherif Ramadan in php.internals (Thu, 15 Nov 2012 21:23:48 -0500): People have been talking about and educating others about the deprecation of ext/mysql for quite some time now. I'm sure that it could be more clearly voiced from an official PHP Project stand-point, but we're down-playing the amount of education that has already gone underway here. Nevertheless, I had only a faint idea it was going to be deprecated. I hardly ever look at the manual for the mysql_ functions because they haven't changed for years. Re-using existing code just works. I think you are overestimating the effect of those talks. Actually, I'm not. One of the reasons most people only know it's being deprecated in passing (your faint idea) is because there has been minimal action from the PHP Project on this. As you can see by the level of activity on this thread there is no real consensus on what should be done here. So the only action from the project so far has been inaction. The ones doing the informing are mostly speaking as individuals, whether they are core developers or not, developers of other PHP OSS frameworks/projects, they are basically divided. Their voices are not heard as one. But they are there and that's why people are aware of the deprecation to come. Obviously there is a benefit in standing united on this and making those voices heard more loudly and unanimously. The fact that you don't regularly look at the manual for functions you know by heart is one of the main arguments I'm making for adding E_DEPRECATED warnings to the mysql_connect/pconnect functions and why I'm advocating this RFC so vivaciously. I want developers, such as yourself, to have as much exposure as possible to the fact that the extension is being deprecated. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where did the _logo_ functions go?
On Fri, Nov 16, 2012 at 10:38 PM, Sherif Ramadan theanomaly...@gmail.comwrote: Obviously it doesn't make sense to use the same function names for the data uris, but why weren't new functions added to expose the data uris to userspace in the same way we used to expose the guids to userspace? It only seems to make sense that we'd continue to do that and it's such a simple fix to replace the functions with new ones. I honestly don't care too much about this particular feature myself, but it sounds pretty silly that this PR did not include the new functions for exposing the uris. My 0.2 cents... Why would you need those data uris? I mean, if you want to embed a PHP logo, then just embed that logo. If you want to put an image on a website, you would usually also just include that .png, rather than creating a data URI from it and embedding that. I don't see a reason to expose those uris. Nikita
