On Fri, Nov 16, 2012 at 10:38 PM, Sherif Ramadan wrote:
> 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 ma
On Fri, Nov 16, 2012 at 2:47 PM, Jan Ehrhardt 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 offi
On Nov 16, 2012, at 19:06, Ronald Chmara 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
On Fri, Nov 16, 2012 at 6:10 AM, Ferenc Kovacs wrote:
>
>
>
> On Fri, Nov 16, 2012 at 3:31 AM, Sherif Ramadan
> wrote:
>>
>> On Thu, Nov 15, 2012 at 8:26 PM, Philip Olson wrote:
>> > Hello geeks,
>> >
>> > Why does PHP 5.5 remove the *_logo_* functions? Is this a security
>> > related move? Shou
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 a
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_
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
buil
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 wrote:
> On 11/15/12 3:11 PM, Anthony Ferrara wrote:
>>
>> That's my suggestion. Officia
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 lik
On Thu, Nov 15, 2012 at 10:38 PM, Johannes Schlüter
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
> req
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 stub
2012/11/16 Rasmus Lerdorf :
> On 11/16/2012 09:32 AM, Patrick ALLAERT wrote:
>> 2012/11/16 Rasmus Lerdorf :
>>> 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
On 11/16/2012 09:32 AM, Patrick ALLAERT wrote:
> 2012/11/16 Rasmus Lerdorf :
>> 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
2012/11/16 Rasmus Lerdorf :
> 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 my
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
Rasmus Lerdorf wrote:
> 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 th
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
>
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 wi
> 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
On Fri, Nov 16, 2012 at 3:31 AM, Sherif Ramadan wrote:
> On Thu, Nov 15, 2012 at 8:26 PM, Philip Olson 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
2012/11/12 Adam Harvey :
> 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
2012/11/12 Adam Harvey :
> 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
On Nov 16, 2012, at 3:16, David Muir 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 f
On Nov 16, 2012, at 5:48, Levi Morrison 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 tra
On Nov 15, 2012, at 22:28, Will Fitch 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 mai
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 you
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.w
hi Philip,
On Fri, Nov 16, 2012 at 10:25 AM, Philip Olson 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 abo
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_DE
hi Rasmus,
On Fri, Nov 16, 2012 at 9:36 AM, Rasmus Lerdorf wrote:
> On 11/15/2012 11:27 PM, Pierre Joye wrote:
>> hi Anthony,
>>
>> On Thu, Nov 15, 2012 at 9:11 PM, Anthony Ferrara wrote:
>>
Actually, no it wouldn't. You still get the overhead of the error, plus
> any custom error handl
> 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 neve
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
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 :
> On 11/15/2012 11:27 PM, Pierre Joye wrote:
>> hi Anthony,
>>
>> On Thu, Nov 15, 2012 at 9:11 PM, Anthony Ferrara wrote:
>>
A
On 11/15/2012 11:27 PM, Pierre Joye wrote:
> hi Anthony,
>
> On Thu, Nov 15, 2012 at 9:11 PM, Anthony Ferrara 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
34 matches
Mail list logo
