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
case it still only has apache 2.2 and php5.3!!! If the distributions are not
using 5.4 what chance is there of the ISP's switching?
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?
--
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
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?
Agreed, but as I said above, I think the distributions are using 5.4,
generally speaking.
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.)
So I think the answer, largely, is "build it and they will come".
I'm not claiming that our migration documentation or BC are perfect as
they stand. They can always be improved. But beyond documentation, I'm
not sure what else we can do from Internals, short of sticking a fork
in the language, calling it done, and never adding another feature.
Adam
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,
5.3 and 5.4 setups to make sure of that. The hassle at the moment is just silly
little things that the developer could quite easily avoided if they also still
considered the end users situation? When a users site goes down, THEY tend not
to be competent enough to fix the problem ... and then saying 'you need to
upgrade php' is even less helpful. Migration can be made hassle free, but WE
need to make that happen! Some of the black holes created by PHP5.3 and 5.4 are
well documented, but unless developers take the care to work around them sites
go down, and then getting an ISP to fix the background installation is not
necessarily easy.
So I think the answer, largely, is "build it and they will come".
I'm not claiming that our migration documentation or BC are perfect as
they stand. They can always be improved. But beyond documentation, I'm
not sure what else we can do from Internals, short of sticking a fork
in the language, calling it done, and never adding another feature.
In hindsight PHP5.3 should have been labelled PHP6 and the 5.2 supported a
little longer. 60% of the world still has the latest identified security
problems in their installations :( It's Internals that decides when a version is
dropped, but I don't think enough consideration was given this time to the end
users?
( I'm looking again at another distribution since SUSE seems to in something of
a mire at the moment :( But having used it since the late 90's ... )
--
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
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
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
PHP5.2. Telling me that this is my problem is just another kick in the teeth!
Helping to solve the problem would also help everybody else upgrade TO PHP5.4?
UNTIL the whole of the PHP infrastructure is brought up to the current
'standards', can we at least have a supported version of PHP that actually
supports what is being shipped. Having spent weeks 'just fixing the errors that
E_STRICT reports', I am now at the stage of having to fix PEAR so that it is
strict compliant. "just have to find a way to manage it" was asking here if
anybody is doing ANYTHING about it, but that seems to have fizzled out again :(
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.
--
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
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:
- Ignore our users asking for warnings on broken code, since somebody
might have problems upgrading when his code is broken. - 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?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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 asE_STRICTis 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 ...
--
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
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 asE_STRICTis 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
explain it would be nice. "Strict" warnings are issued when your code is
doing something that the designers of the engine consider a bad idea,
which in vast majority of cases means a bug.
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
Good example. "static" function is called static for a reason, and the
reason is it does not belong to an object but to a class, thus it can
not and should not have $this. Code that uses $this in a static function
is thus broken and needs to be fixed. In overwhelming majority of the
code this is a bug. If some code used it as feature, it was a bad idea,
and the time of this bad idea is gone now.
'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?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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
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 :(
--
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
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
any "clever" tricks that abuse PHP constructs for what they weren't
meant to do - and you have reasonable assurance it will keep working fine.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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
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 beenextremely 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
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
Hi!
On 01 August 2012 at 09:36 Lester Caine lester@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 beenextremely 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
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)
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 - G8HFLContact - 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--
--
Andrew Faulds
http://ajf.me/
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
now, but knowing how to fix it isn't helped if the ISP will not turn it on
again. One ends up going through sites worth of PHP manually fixing it,
something which I should perhaps be charging the customers for - but it's not
THEIR problem is it :( OK some of those site have <? to clean up as well, but
it's interesting how many sites HAD already been cleaned for that in PHP5.2 ...
--
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
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
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
php.ini-dist? And become friends with distributions to suggest real default
values to be used all across the world?
Today it feels dirty to mention "default values" in the PHP world as really
this concept does not exist.
Regards,
Philip
Andrew Faulds wrote:
Then can you explain why <?= has stopped working on shared hosting on
a numberof 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 ...
Well, perhaps in your particular case, but that would still have broken
apps that actually use short_open_tags as opposed to just the short echo
tag. If you have no control over your php.ini and whoever controls it
decides to change it and your app breaks, then your beef should be with
them, not with us. We try to make sure apps don't break from one version
to another if you keep your config the same. We will guide and warn as
appropriate and let people know via the Upgrading guides what the
ramifications are of the various changes.
Also most ISPs provide .htaccess and short_open_tag is a PHP_INI_PERDIR
setting so it is user-settable in the .htaccess. Are you sure the 3 ISPs
you mentioned all disallow .htaccess while at the same time changing
their global php.ini config such that it breaks your apps?
-Rasmus
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 asE_STRICTis 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! )
Let me just throw this out there in case nobody's thought of it yet: Why
don't we draft a clear policy (an RFC maybe?) with regard to how BC is
handled with different version increments. Here's a rough sketch of what
I'm proposing in terms of that policy:
Version A.b.c
A: Major version increment. We maintain the fundamental syntax and other
defining characteristics of PHP, but everything else is fair game. We
make it clear to all users that existing PHP scripts from previous A
version increments are not supported. There is an understanding that,
depending on your code, chances are you'll have to make at least some
significant modifications to it. We will make every effort to document
these behavioral differences. Because adoption is a gradual process
anyway, people should have sufficient time to update their code before the
majority of hosts make the switch, particularly if we document these in
advance.
b: Minor BC breaks can occur, but should be avoided when possible. If
there is a BC issue, E_DEPRECATED should be used until the next b increment
if at all possible to soften the impact.
c: BC breaks should not occur here. Possible rare exception for
critical/urgent bugfixes.
This more or less mirrors what we seem to be doing already; indeed, maybe
it already is documented somewhere? However, the fact that these arguments
keep coming up makes me doubt that possibility.
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 ...
+1
I don't know the answer, but it sounds to me like a perfectly reasonable
question to ask. =)
--Kris