Developing PHP

Lester Caine | 30 Jul 2012 10:02

Picon

[PHP-DEV] Bringing users along ...

Having just been helping another unsophisticated user, the growing problem of 
incompatibility between versions is starting to hit harder. So can developers 
please start taking a little more care with the support of existing users!

 From w3techs ...
http://w3techs.com/technologies/details/pl-php/5/all

Over 60% of sites are still using 5.2 or before, and the majority of those are 
probably shared hosting where it is the ISP who decides which version is 
supplied. I'd love to know who is using PHP5.5! but 5.4 still only has a very 
small take-up after all this time.

Moving people from 5.2 is probably going to be as bad as killing off PHP4 and 
4.6% of sites are still using that! But the main problem starting to happen now 
is that developers are upgrading projects to use 5.3 and 5.4 features, but 
simply assuming that the user is working with the latest. 'Security warnings' 
get people to upgrade their own installs, but on top of a stack provided by 
their hosting company. Result ... sites stop working ... please can developers 
take a little more care checking for compatibility, and at least warn if 
something will not work on earlier versions of PHP.

Promoting PHP5.4 to the distributions should perhaps be done a little more? SUSE 
still does not have even an experimental version of 5.4, and the private build 
doesn't work with it's own apache 2.4 or the stock 2.2.

I had switched from using the stock builds to manually installing both apache 
and php, but this is opening up yet another can of worms. On three different 
12.1 installations I now have three different structures of configuration setup 
:( and I'm not quite sure WHAT I did differently! I could wait for SUSE12.2 
except that has been delayed due to problems making it stable again, and in any

(Continue reading)

Adam Harvey | 30 Jul 2012 10:45

Picon

Re: [PHP-DEV] Bringing users along ...

On 30 July 2012 16:02, Lester Caine <lester <at> lsces.co.uk> wrote:
> Moving people from 5.2 is probably going to be as bad as killing off PHP4
> and 4.6% of sites are still using that! But the main problem starting to
> happen now is that developers are upgrading projects to use 5.3 and 5.4
> features, but simply assuming that the user is working with the latest.
> 'Security warnings' get people to upgrade their own installs, but on top of
> a stack provided by their hosting company. Result ... sites stop working ...
> please can developers take a little more care checking for compatibility,
> and at least warn if something will not work on earlier versions of PHP.

What, specifically, have you found that isn't covered in the release
notes and/or migration guide for PHP 5.3 and 5.4? Documentation bugs
would be awesome here. (Patches would be even more awesome.)

It's hard to improve this without detailed information, since the
migration guides feel reasonably complete at this point.

> Promoting PHP5.4 to the distributions should perhaps be done a little more?

What additional promotion do you have in mind?

> SUSE still does not have even an experimental version of 5.4, and the
> private build doesn't work with it's own apache 2.4 or the stock 2.2.

SUSE seem to be an outlier here: Fedora 17 has PHP 5.4, Ubuntu 12.10
will ship with 5.4, Debian testing and unstable have 5.4, FreeBSD has
5.4 in ports, and Arch has 5.4, to name but a few.

> If the distributions are not using 5.4 what chance is there of the ISP's
> switching?

(Continue reading)

Lester Caine | 30 Jul 2012 11:14

Picon

Re: [PHP-DEV] Bringing users along ...

Adam Harvey wrote:
> What, specifically, have you found that isn't covered in the release
> notes and/or migration guide for PHP 5.3 and 5.4? Documentation bugs
> would be awesome here. (Patches would be even more awesome.)
>
> It's hard to improve this without detailed information, since the
> migration guides feel reasonably complete at this point.

I'm appealing here to the developers who use that information !!!!

The latest problem was with a 'TIKI' which stopped working after a 'security 
update', but the newer version did not bother to check that 5.3 was available 
and it messed up on the customers 5.2 setup. I've helped with several problems 
over the last few months, either down to PHP version changes or project changes 
that did not watch for what PHP version was running.

>> So what is the best way of getting the user base behind us using even PHP5.4
>> so that any discussion of even more changes in PHP6 makes sense at all?
>
> The same chicken and egg scenario once existed around PHP 5. The
> community saw the merit in PHP 5 (5.2, specifically), and created
> gophp5.org (now squatted, sadly) which was a rather successful
> campaign to raise awareness of the issue, and ended with the situation
> we're now in where most actively-developed frameworks and projects
> require PHP 5.2 or 5.3 and use their features. (It's also worth
> remembering that the BC concerns aren't as drastic for a lot of people
> as they seem to be for you, Lester — a lot of codebases seem to have
> been migrated from PHP 4 to 5 with little to no hassle.)

I'm still making sure that upgrades run on 5.2, but I've had to set up a 5.2,

(Continue reading)

Rasmus Lerdorf | 30 Jul 2012 17:18

Re: [PHP-DEV] Bringing users along ...

On 07/30/2012 01:02 AM, Lester Caine wrote:
> Having just been helping another unsophisticated user, the growing
> problem of incompatibility between versions is starting to hit harder.
> So can developers please start taking a little more care with the
> support of existing users!

Lester, we get it. Your job is to maintain and support legacy code and
you are grumpy about it. You have posted about it repeatedly for years.
And as much as you don't think we do enough, we actually put a lot of
emphasis on not breaking backward compatibility. But it is always a
trade off. Every new feature, bug fix or security fix introduces some
level of backward compatibility issue. We try to minimize those BC
breaks, but they will continue to happen. You will just have to  find a
way to manage it.

-Rasmus

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Lester Caine | 1 Aug 2012 08:19

Picon

Re: [PHP-DEV] Bringing users along ...

Rasmus Lerdorf wrote:
>> Having just been helping another unsophisticated user, the growing
>> >problem of incompatibility between versions is starting to hit harder.
>> >So can developers please start taking a little more care with the
>> >support of existing users!
> Lester, we get it. Your job is to maintain and support legacy code and
> you are grumpy about it. You have posted about it repeatedly for years.
> And as much as you don't think we do enough, we actually put a lot of
> emphasis on not breaking backward compatibility. But it is always a
> trade off. Every new feature, bug fix or security fix introduces some
> level of backward compatibility issue. We try to minimize those BC
> breaks, but they will continue to happen. You will just have to  find a
> way to manage it.

At the moment it would seem that 'upgrades' are spiralling out of control 
everywhere :(

I'm currently having to buy extra monitors and take them out to site simply 
because some git at M$ has decided that Windows XP can only be used if every 
display has one attached! The bulk of my infrastructure is 'headless' as far as 
the desktop, as the remote displays are only controlled over the network. LINUX 
has added the same 'improvement' so that none of my servers run properly as they 
are attached to KVM's and will no longer boot up with the right screen layout. 
The fix is to replace thousands of pounds worth of hardware :( I can't stop 
windows/linux updates as the local IT people require that they run.

The current raft of PHP problems arise from the fact that "we actually put a lot 
of emphasis on not breaking backward compatibility" seems just to be lip service 
to the real problem ... Taking stuff out in PHP5.4 would be fine if people are 
upgrading from PHP5.3, but they are not. The bulk of the live code is still on

(Continue reading)

Stas Malyshev | 1 Aug 2012 08:28

Re: [PHP-DEV] Bringing users along ...

Hi!

> The current raft of PHP problems arise from the fact that "we actually put a lot 
> of emphasis on not breaking backward compatibility" seems just to be lip service 
> to the real problem ... Taking stuff out in PHP5.4 would be fine if people are 

So what would happen if it would be real BC? I mean, if you want 5.4, we
need to make some changes. Some of these changes will make either
impossible or impractical to support broken code, and some broken code
warnings were actually requested by the users. So I see one of the two ways:
1. Ignore our users asking for warnings on broken code, since somebody
might have problems upgrading when his code is broken.
2. Listen to our users asking for warning on broken code, and prefer
future clean code to old broken one.

Do you see any third way to do? If so, please describe.

> Helping to solve the problem would also help everybody else upgrade TO PHP5.4?

OK, so what help do you require?

> Add to this the fun getting Apache 2.4 configured with PHP and my old framework, 
> it is no wonder I grumpy ... I would much rather be adding functionality and 
> working on NEW stuff than fixing the problems other people leave behind. And I 
> don't need any of the new PHP5.3/44 features to write my own new code.

While I can sympathize with your problems fixing bad code left by other
people, I am not sure how it is relevant on this list - is there
something that people present on this list can help you with? What is it?
--

--

(Continue reading)

Lester Caine | 1 Aug 2012 08:55

Picon

Re: [PHP-DEV] Bringing users along ...

Stas Malyshev wrote:
>> Helping to solve the problem would also help everybody else upgrade TO PHP5.4?
> OK, so what help do you require?
PEAR and PECL that work with PHP5.4 out of the box?
At least the core of PEAR that does not throw strict warnings from a stock 
install of PHP5.4 as E_STRICT is on.

>> >Add to this the fun getting Apache 2.4 configured with PHP and my old framework,
>> >it is no wonder I grumpy ... I would much rather be adding functionality and
>> >working on NEW stuff than fixing the problems other people leave behind. And I
>> >don't need any of the new PHP5.3/44 features to write my own new code.
> While I can sympathize with your problems fixing bad code left by other
> people, I am not sure how it is relevant on this list - is there
> something that people present on this list can help you with? What is it?

I think that this is the problem here. "fixing bad code" is simply not a 
statement that I recognise! I am not fixing bad code, I am re-writing much of it 
simply because the style is no longer acceptable, or somebody changed a default 
setting without considering the consequences ( <?= not working in PHP5.3 is 
STILL biting as ISP are only upgrading to PHP5.3! )

I still have not had a proper answer to a question I repeatedly ask. "Please can 
we have some tutorials on how 'strict' styling should be used?" I'm fixing the 
warnings created but I still do not fully understand what I am fixing. The main 
rework area has been not being able to use '$this' in static functions, even if 
the function checks $this and defaults to the static code internally. Adding 
'public/private/protected/static/self ...' and using them in the right places is 
well documented in bits and pieces, but there is no general 'how to' put the 
whole together? I suppose someone will want to add traits and the rest to that, 
but just a simple style guide for the basics would be nice ...

(Continue reading)

Stas Malyshev | 1 Aug 2012 09:17

Re: [PHP-DEV] Bringing users along ...

Hi!

> PEAR and PECL that work with PHP5.4 out of the box?
> At least the core of PEAR that does not throw strict warnings from a stock 
> install of PHP5.4 as E_STRICT is on.

For PEAR is think it is a wrong list, as for PECL most extensions are
maintained by their maintainers, and internals specifically works only
on the core.

> I think that this is the problem here. "fixing bad code" is simply not a 
> statement that I recognise! I am not fixing bad code, I am re-writing much of it 
> simply because the style is no longer acceptable, or somebody changed a default 

You are trying to reframe the same meaning with different words, but the
meaning does not change - the code that is no longer acceptable in 5.4
is not acceptable for a reason. Usually the reason is that the code is
broken or using PHP in a wrong way - such as silently converting nulls
to objects, strings to arrays, arrays to strings, etc.

> setting without considering the consequences ( <?= not working in PHP5.3 is 
> STILL biting as ISP are only upgrading to PHP5.3! )

Err, I'm not sure what you mean - <?= certainly works in 5.3.

> I still have not had a proper answer to a question I repeatedly ask. "Please can 
> we have some tutorials on how 'strict' styling should be used?" I'm fixing the 
> warnings created but I still do not fully understand what I am fixing. The main 

I, for one, do not understand what you are asking. If somebody could

(Continue reading)

Lester Caine | 1 Aug 2012 09:42

Picon

Re: [PHP-DEV] Bringing users along ...

Stas Malyshev wrote:
>> setting without considering the consequences ( <?= not working in PHP5.3 is
>> STILL biting as ISP are only upgrading to PHP5.3! )
>
> Err, I'm not sure what you mean - <?= certainly works in 5.3.
Only with short tags on ... 5.4 has detached it from that, but 5.3 still 
switches it off by default, and convincing ISP to switch short tags on again is 
a lost cause :( Fixing it in PHP5.3 was rejected :(
Heck it took three days to get a reply that they had got a request about it, by 
which time everything was switched back to '<?php echo' ...
----

>> 'public/private/protected/static/self ...' and using them in the right places is
>> well documented in bits and pieces, but there is no general 'how to' put the
>> whole together? I suppose someone will want to add traits and the rest to that,
>
> How to put what together? The manual page for static states explicitly:
>
> Because static methods are callable without an instance of the object
> created, the pseudo-variable $this is not available inside the method
> declared as static.
>
> What other howto is needed for this?

Fine, so I just add 'static' rework all the code, and fix the error, but I think 
I should also be adding public as well? It's not needed to clear the warning, 
but should I also be going through every function and adding that, as well? 
Again, it's not a bug, but is all this extra syntax needed to get things into 
the right style for the next changes in PHP? You have to bear in mind than a lot 
of this code is ten years old and has been working fine all that time. I don't

(Continue reading)

Stas Malyshev | 1 Aug 2012 09:57

Re: [PHP-DEV] Bringing users along ...

Hi!

> Only with short tags on ... 5.4 has detached it from that, but 5.3 still 
> switches it off by default, and convincing ISP to switch short tags on again is 
> a lost cause :( Fixing it in PHP5.3 was rejected :(

Errm... So you are complaining we're not going back in time now and make
different decision about PHP 5.3 that was made years ago? Or what is
your point exactly?

> Fine, so I just add 'static' rework all the code, and fix the error, but I think 
> I should also be adding public as well? It's not needed to clear the warning, 

If your functions are public, I'd recommend adding public. However, as
the same manual states, public is optional for BC reasons and if access
is omitted, public is assumed. Same manual, same page, one paragraph above:

For compatibility with PHP 4, if no visibility declaration is used, then
the property or method will be treated as if it was declared as public.

> mind so much some of the rework, but I've no confidence that I will not be doing 
> this exercise again next year - on the same code :(

If you want somebody to assure you that the code that nobody except you
have seen would not contain any problems after you fix some of the
problems you have now but nobody except you knows about - then I'm
afraid it's not something that anybody here is able to promise you. If
you have some specific proposal - let's hear it. Otherwise I'd recommend
following current best practices for writing good PHP code - e.g. what
described in the manual and many framework style guides, etc., don't use

(Continue reading)

Rasmus Lerdorf | 1 Aug 2012 10:08

Re: [PHP-DEV] Bringing users along ...

On 08/01/2012 12:57 AM, Stas Malyshev wrote:
> Hi!
> 
>> Only with short tags on ... 5.4 has detached it from that, but 5.3 still 
>> switches it off by default, and convincing ISP to switch short tags on again is 
>> a lost cause :( Fixing it in PHP5.3 was rejected :(
> 
> Errm... So you are complaining we're not going back in time now and make
> different decision about PHP 5.3 that was made years ago? Or what is
> your point exactly?

Note also that we have been *extremely* conservative with the
short_open_tag setting because we know it can break old code. To this
day even in PHP 5.4 it is still on by default as it was in PHP 5.3.
Since PHP 5.1.0 which was released in 2005 we have suggested that people
disable it in their php.ini because of the obvious problems it causes
with respect to other things that use the XML PI tag, but we have in no
way forced their hands. If you simply upgraded PHP and didn't change
your php.ini, nothing related to short_open_tags would have broken in
the past 15 years.

-Rasmus

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Lester Caine | 1 Aug 2012 10:36

Picon

Re: [PHP-DEV] Bringing users along ...

Rasmus Lerdorf wrote:
>>> Only with short tags on ... 5.4 has detached it from that, but 5.3 still
>>> >>switches it off by default, and convincing ISP to switch short tags on again is
>>> >>a lost cause:(  Fixing it in PHP5.3 was rejected:(
>> >
>> >Errm... So you are complaining we're not going back in time now and make
>> >different decision about PHP 5.3 that was made years ago? Or what is
>> >your point exactly?
> Note also that we have been*extremely*  conservative with the
> short_open_tag setting because we know it can break old code. To this
> day even in PHP 5.4 it is still on by default as it was in PHP 5.3.
> Since PHP 5.1.0 which was released in 2005 we have suggested that people
> disable it in their php.ini because of the obvious problems it causes
> with respect to other things that use the XML PI tag, but we have in no
> way forced their hands. If you simply upgraded PHP and didn't change
> your php.ini, nothing related to short_open_tags would have broken in
> the past 15 years.

Then can you explain why <?= has stopped working on shared hosting on a number 
of ISP's who have recently updated from 5.2 to 5.3 ...
The default on PHP5.3 is to switch 'short_open_tag' off? which also disables <?= 
which is a bit of a problem when the sites are using templating which relies on 
it :( The horse has bolted now, but it would have been nice when this particular 
problem was highlighted that PHP5.3 was backported with the fix that HAS been 
applied to 5.4 ...
This is an example of a simple problem, not of 'buggy code' :(

--

-- 
Lester Caine - G8HFL
-----------------------------

(Continue reading)

Andrew Faulds | 1 Aug 2012 13:58

Re: [PHP-DEV] Bringing users along ...

 Hi!

On 01 August 2012 at 09:36 Lester Caine <lester <at> lsces.co.uk> wrote:

> Rasmus Lerdorf wrote:
> >>> Only with short tags on ... 5.4 has detached it from that, but 5.3 still
> >>> >>switches it off by default, and convincing ISP to switch short tags on
> >>> >>again is
> >>> >>a lost cause:(  Fixing it in PHP5.3 was rejected:(
> >> >
> >> >Errm... So you are complaining we're not going back in time now and make
> >> >different decision about PHP 5.3 that was made years ago? Or what is
> >> >your point exactly?
> > Note also that we have been*extremely*  conservative with the
> > short_open_tag setting because we know it can break old code. To this
> > day even in PHP 5.4 it is still on by default as it was in PHP 5.3.
> > Since PHP 5.1.0 which was released in 2005 we have suggested that people
> > disable it in their php.ini because of the obvious problems it causes
> > with respect to other things that use the XML PI tag, but we have in no
> > way forced their hands. If you simply upgraded PHP and didn't change
> > your php.ini, nothing related to short_open_tags would have broken in
> > the past 15 years.
>
> Then can you explain why <?= has stopped working on shared hosting on a number
> of ISP's who have recently updated from 5.2 to 5.3 ...

Which? "A number of ISP's"? How many are we talking about?
Also, is it our problem if ISPs changed their configuration during an upgrade?
How do we know it's our fault? Debian or RedHat or some other common base
distribution may have changed the configuration - you realise that they are most

(Continue reading)

Lester Caine | 1 Aug 2012 14:38

Picon

Re: [PHP-DEV] Bringing users along ...

Andrew Faulds wrote:
>> Then can you explain why <?= has stopped working on shared hosting on a number
>> >of ISP's who have recently updated from 5.2 to 5.3 ...
> Which? "A number of ISP's"? How many are we talking about?
> Also, is it our problem if ISPs changed their configuration during an upgrade?
> How do we know it's our fault? Debian or RedHat or some other common base
> distribution may have changed the configuration - you realise that they are most
> likely using a slightly modified version from a distribution, and use the
> distribution defaults, or a modified version of that, yes? Probably not the
> official PHP version directly built from source, I'd figure.
>
>> >The default on PHP5.3 is to switch 'short_open_tag' off? which also disables
>> ><?=
> I'm fairly sure Rasmus said it wasn't. And, being Rasmus, I think I can trust
> him on that;)
>
> (I don't really use short tags, so I don't know myself)

The default if it's not included in the .ini is ON, but the sample .ini's both 
switch it off, and that is what the distributions follow when creating a clean 
install.

ALL that was required when the problem was identified was that <?= was handled 
in PHP5.3 the same way it IS now handled in PHP5.4 and the problem would not 
exist. This is an example of not thinking through to production a simple change 
in the core PHP ...

HOPEFULLY ISP's will start leapfrogging 5.3 anyway and upgrade direct to 5.4, 
but since 60% of live users are currently on 5.2 the potential number of users 
with a problem could be quite large. I've hit it myself on three different ISP's

(Continue reading)

Johannes Schlüter | 1 Aug 2012 16:01

Picon

Re: [PHP-DEV] Bringing users along ...

On Wed, 2012-08-01 at 13:38 +0100, Lester Caine wrote:
> The default if it's not included in the .ini is ON, but the
> sample .ini's both switch it off, and that is what the distributions
> follow when creating a clean install.
> 
> ALL that was required when the problem was identified was that <?= was
> handled in PHP5.3 the same way it IS now handled in PHP5.4 and the
> problem would not exist. This is an example of not thinking through to
> production a simple change in the core PHP ...

The default are the compiled in values. The provided ini files are
suggestions with comments for improving the configuration above the
default. Those values aren't the default for exactly the reason you
identified. If distributions "force" those values on you complain there.

And no, we won't change the core language (<?= like in 5.4) in 5.3.
There should only be bugfixes, no feature changes.

If you want to help please test 5.5 snapshots before the release and
identify possible issues there. As Rasmus and others said we try hard to
make migration simple while allowing evolution to happen, sometimes we
fail, that can only be fixed before a release, we can't change the past,
yet.

johannes

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

(Continue reading)

Philip Olson | 1 Aug 2012 17:28

Re: [PHP-DEV] Bringing users along ...


On Aug 1, 2012, at 7:01 AM, Johannes Schlüter wrote:

> On Wed, 2012-08-01 at 13:38 +0100, Lester Caine wrote:
>> The default if it's not included in the .ini is ON, but the
>> sample .ini's both switch it off, and that is what the distributions
>> follow when creating a clean install.
>> 
>> ALL that was required when the problem was identified was that <?= was
>> handled in PHP5.3 the same way it IS now handled in PHP5.4 and the
>> problem would not exist. This is an example of not thinking through to
>> production a simple change in the core PHP ...
> 
> The default are the compiled in values. The provided ini files are
> suggestions with comments for improving the configuration above the
> default. Those values aren't the default for exactly the reason you
> identified. If distributions "force" those values on you complain there.
> 
> And no, we won't change the core language (<?= like in 5.4) in 5.3.
> There should only be bugfixes, no feature changes.
> 
> If you want to help please test 5.5 snapshots before the release and
> identify possible issues there. As Rasmus and others said we try hard to
> make migration simple while allowing evolution to happen, sometimes we
> fail, that can only be fixed before a release, we can't change the past,
> yet.

One problem here is that we do not distribute a php.ini file with default 
values. The "what is the default value?" topic is real and comes up often. 
Is it time we get back to our roots and include a file like the old

(Continue reading)

Rasmus Lerdorf | 1 Aug 2012 17:18

Re: [PHP-DEV] Bringing users along ...

On 08/01/2012 05:38 AM, Lester Caine wrote:
> Andrew Faulds wrote:
>>> Then can you explain why <?= has stopped working on shared hosting on
>>> a number
>>> >of ISP's who have recently updated from 5.2 to 5.3 ...
>> Which? "A number of ISP's"? How many are we talking about?
>> Also, is it our problem if ISPs changed their configuration during an
>> upgrade?
>> How do we know it's our fault? Debian or RedHat or some other common base
>> distribution may have changed the configuration - you realise that
>> they are most
>> likely using a slightly modified version from a distribution, and use the
>> distribution defaults, or a modified version of that, yes? Probably
>> not the
>> official PHP version directly built from source, I'd figure.
>>
>>> >The default on PHP5.3 is to switch 'short_open_tag' off? which also
>>> disables
>>> ><?=
>> I'm fairly sure Rasmus said it wasn't. And, being Rasmus, I think I
>> can trust
>> him on that;)
>>
>> (I don't really use short tags, so I don't know myself)
> 
> The default if it's not included in the .ini is ON, but the sample
> .ini's both switch it off, and that is what the distributions follow
> when creating a clean install.
> 
> ALL that was required when the problem was identified was that <?= was

(Continue reading)

Kris Craig | 1 Aug 2012 09:27

Picon

Re: [PHP-DEV] Bringing users along ...

On Tue, Jul 31, 2012 at 11:55 PM, Lester Caine <lester <at> lsces.co.uk> wrote:

> Stas Malyshev wrote:
>
>> Helping to solve the problem would also help everybody else upgrade TO
>>> PHP5.4?
>>>
>> OK, so what help do you require?
>>
> PEAR and PECL that work with PHP5.4 out of the box?
> At least the core of PEAR that does not throw strict warnings from a stock
> install of PHP5.4 as E_STRICT is on.
>
>
>  >Add to this the fun getting Apache 2.4 configured with PHP and my old
>>> framework,
>>> >it is no wonder I grumpy ... I would much rather be adding
>>> functionality and
>>> >working on NEW stuff than fixing the problems other people leave
>>> behind. And I
>>> >don't need any of the new PHP5.3/44 features to write my own new code.
>>>
>> While I can sympathize with your problems fixing bad code left by other
>> people, I am not sure how it is relevant on this list - is there
>> something that people present on this list can help you with? What is it?
>>
>
> I think that this is the problem here. "fixing bad code" is simply not a
> statement that I recognise! I am not fixing bad code, I am re-writing much
> of it simply because the style is no longer acceptable, or somebody changed

(Continue reading)

Andrew Faulds | 1 Aug 2012 16:30

Re: [PHP-DEV] Bringing users along ...

Hmm, in that case, why do ini defaults differ significantly from those compiled in?

--
Sent from Samsung Mobile
Andrew Faulds
http://ajf.me/

Johannes Schlüter <johannes <at> schlueters.de> wrote:

On Wed, 2012-08-01 at 13:38 +0100, Lester Caine wrote:
> The default if it's not included in the .ini is ON, but the
> sample .ini's both switch it off, and that is what the distributions
> follow when creating a clean install.
> 
> ALL that was required when the problem was identified was that <?= was
> handled in PHP5.3 the same way it IS now handled in PHP5.4 and the
> problem would not exist. This is an example of not thinking through to
> production a simple change in the core PHP ...

The default are the compiled in values. The provided ini files are
suggestions with comments for improving the configuration above the
default. Those values aren't the default for exactly the reason you
identified. If distributions "force" those values on you complain there.

And no, we won't change the core language (<?= like in 5.4) in 5.3.
There should only be bugfixes, no feature changes.

If you want to help please test 5.5 snapshots before the release and
identify possible issues there. As Rasmus and others said we try hard to
make migration simple while allowing evolution to happen, sometimes we

(Continue reading)

Lester Caine | 2 Aug 2012 12:31

Picon

Re: [PHP-DEV] Bringing users along ...

Andrew Faulds wrote:
> Hmm, in that case, why do ini defaults differ significantly from those compiled in?
There was a discussion about that not long ago? Aren't the PHP5.4 bits now all 
tidied so that the defaults match a production .ini file? So only development 
changes something?

I've not checked that recently, as I'm still working through how to set up a 
PHP5.4 .ini configuration that does the best it can for PHP5.2, but I am now 
hitting the 'global' problem on many legacy sites :(

-- 
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

Return

Return to gmane.comp.php.devel.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane