Hi!
- Session fails to save if it contains special chars
Session data or session variable names? If the former, it is a strange
bug but certainly needs fixing. If it's the latter, it is the same
exotic issue, which I suspect very small number of people actually have.
Still, I'm ok with adding
Hi Stas,
On Sun, Aug 11, 2013 at 7:54 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
- Session fails to save if it contains special chars
Session data or session variable names? If the former, it is a strange
bug but certainly needs fixing. If it's the latter, it is the same
exotic
On 8 August 2013 23:31, Yasuo Ohgaki yohg...@ohgaki.net wrote:
How php_serialize would cause BC issues for PHP users?
Not everyone uses PHP in the way you would expect. Just how many sites out
there do you think use PHPs session functionality? I'd go for hundreds of
millions, and that's a
Hi Leigh,
On Fri, Aug 9, 2013 at 5:28 PM, Leigh lei...@gmail.com wrote:
On 8 August 2013 23:31, Yasuo Ohgaki yohg...@ohgaki.net wrote:
How php_serialize would cause BC issues for PHP users?
Not everyone uses PHP in the way you would expect. Just how many sites out
there do you think use
Leigh wrote:
How php_serialize would cause BC issues for PHP users?
Not everyone uses PHP in the way you would expect. Just how many sites out there
do you think use PHPs session functionality? I'd go for hundreds of millions,
and that's a pretty big target to hit.
If you session_encode()
Hi Lester,
On Fri, Aug 9, 2013 at 6:29 PM, Lester Caine les...@lsces.co.uk wrote:
Leigh wrote:
How php_serialize would cause BC issues for PHP users?
Not everyone uses PHP in the way you would expect. Just how many sites
out there
do you think use PHPs session functionality? I'd go
Yasuo Ohgaki wrote:
If users aren't reading release note of minor version up, then it is users'
fault,
not ours. If it is, we cannot release new PHP.
MANY users don't even know that their hosting has been changed until their sites
stop working ... This happens a lot more often now than it
Blaming the users is simply not acceptable!
That actually depends on the organization's focus. I, for one, will gladly
blame users when they don't care when their software is deprecated. Using
deprecated software is their risk, not ours, especially when they are not
keeping in close contact
Hi!
As I wrote, there is no real BC issue as it's just a matter of ini setting.
There is a BC issue if you need an ini setting. You keep dismissing it
but if it affected the app your business relates on it'd be a major
problem if on upgrade your app breaks and you need to scour release
notes to
Hi Stas,
On Sat, Aug 10, 2013 at 1:53 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
As I wrote, there is no real BC issue as it's just a matter of ini
setting.
There is a BC issue if you need an ini setting. You keep dismissing it
but if it affected the app your business relates on it'd
Hi Stas,
On Sat, Aug 10, 2013 at 1:53 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
We can also take some responsibility for making it easier to
upgrade
That's the reason why I proposed adding php_serialize to 5.5.
Even if there are very few users may have problem with new serializer,
it
Yasuo Ohgaki wrote:
Or make it optional for 5.5 and 5.6, write full documentation about
serializer
and make new serializer default for future releases.
It would work better. There would be enough time for users may have BC
issue. If they do, it would be simple task to adopt because it is plain
Hi Lester,
On Thu, Aug 8, 2013 at 5:26 PM, Lester Caine les...@lsces.co.uk wrote:
We need to help get the rest of the infrastructure working with PHP5.4
before starting work on 5.6 ... let alone 5.5 ...
Since 5.5 is just released, some fixes may be good to add.
However, I agree that released
Sorry I failed at reply to all.
On 8 August 2013 11:38, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Leigh,
On Thu, Aug 8, 2013 at 7:23 PM, Leigh lei...@gmail.com wrote:
Are you keeping it as optional for 5.6 and not the default? If you're
making it default don't we need to vote on BC breaks?
Hi Leigh,
On Thu, Aug 8, 2013 at 7:53 PM, Leigh lei...@gmail.com wrote:
but I'm not sure if it should be default behaviour.
What's the point of having old serialzers that is bonded to
register_globals?
This kind of change should have done when 5.4.0 was released, IMO.
Regards,
--
Yasuo
On 8 August 2013 12:05, Yasuo Ohgaki yohg...@ohgaki.net wrote:
What's the point of having old serialzers that is bonded to
register_globals?
This kind of change should have done when 5.4.0 was released, IMO.
Because somebodies code will depend on functionality not changing, and we
shouldn't
Leigh wrote:
On 8 August 2013 12:05, Yasuo Ohgakiyohg...@ohgaki.net wrote:
What's the point of having old serialzers that is bonded to
register_globals?
This kind of change should have done when 5.4.0 was released, IMO.
Because somebodies code will depend on functionality not changing, and
Hi,
On Thu, Aug 8, 2013 at 9:10 PM, Lester Caine les...@lsces.co.uk wrote:
Leigh wrote:
I can't judge the scope of the break, or how many users will be affected.
I
just want to say that breaks without a good reason shouldn't happen.
Seconded.
In hindsight I personally would have
Hi all,
Current session module has a few limitations due to register_globals
support which is now obsolete. One of them is numeric key indexed session
data. i.e. $_SESSION[1] = $var is not allowed now and it raises error at
R_SHUTDOWN with useless message for debugging.
Hi!
Current session module has a few limitations due to register_globals
support which is now obsolete. One of them is numeric key indexed session
data. i.e. $_SESSION[1] = $var is not allowed now and it raises error at
R_SHUTDOWN with useless message for debugging.
Why is it useful to do
Hi Stas,
On Thu, Aug 8, 2013 at 5:34 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Why is it useful to do this? I don't see how using numerical indexes in
global namespace (and SESSION is one of global namespaces in PHP) is a
good idea. Could you explain the use case here?
Personally, I
Hi!
Personally, I would not use numeric index.
However, users are expecting it to work and there is no way to raise
I don't think it is reasonable to expect it to work, it never worked, it
never was documented to work and there's no real use case for it.
The limitation is come from
Hi Stas
On Thu, Aug 8, 2013 at 10:03 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Personally, I would not use numeric index.
However, users are expecting it to work and there is no way to raise
I don't think it is reasonable to expect it to work, it never worked, it
never was documented
Hi!
Removing unneeded limitations, rather than forcing them to users, is user
friendly and the way to go. IMHO.
If we wrote it from scratch, sure. But if we already have existing and
working one, having people to deal with migrating data and
incompatibilities that arise IMHO is not worth the
Hi Stas,
On Thu, Aug 8, 2013 at 11:03 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Removing unneeded limitations, rather than forcing them to users, is user
friendly and the way to go. IMHO.
If we wrote it from scratch, sure. But if we already have existing and
working one, having
Hi Stas,
On Thu, Aug 8, 2013 at 11:11 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Thu, Aug 8, 2013 at 11:03 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Removing unneeded limitations, rather than forcing them to users, is
user
friendly and the way to go. IMHO.
If we wrote it from
26 matches
Mail list logo
