Hi Folks:
We all want to see Magic Quotes go away. Discussions on this list indicate
several people are concerned with doing this in a safe and orderly
manner. [1][2] To this end, I have posted an RFC at
https://wiki.php.net/rfc/magicquotes_finale
Please read it through, think about it, then post your opinions to the
mailing list.
Thanks,
--Dan
[1] "Vote results" http://marc.info/?t=131089383200001&r=1&w=2
[2] "5.4 features vote" http://marc.info/?t=131019327500001&r=1&w=2
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
personally I'm of the opinion that even 5.4 should actually cause a fatal
error, but I know this not going to happen
5.4 throw an E_DEPRECATED, but with this being rolled into E_ALL, it still
might get ignored
5.4.1 set default to off
5.4.4 throw an E_WARNING or E_FATAL if turned on
On Mon, Jul 18, 2011 at 3:39 PM, Daniel Convissor <
danielc@analysisandsolutions.com> wrote:
Hi Folks:
We all want to see Magic Quotes go away. Discussions on this list indicate
several people are concerned with doing this in a safe and orderly
manner. [1][2] To this end, I have posted an RFC at
https://wiki.php.net/rfc/magicquotes_finalePlease read it through, think about it, then post your opinions to the
mailing list.Thanks,
--Dan
[1] "Vote results" http://marc.info/?t=131089383200001&r=1&w=2
[2] "5.4 features vote" http://marc.info/?t=131019327500001&r=1&w=2--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
personally I'm of the opinion that even 5.4 should actually cause a fatal
error, but I know this not going to happen5.4 throw an E_DEPRECATED, but with this being rolled into E_ALL, it still
might get ignored
5.4.1 set default to off
5.4.4 throw anE_WARNINGor E_FATAL if turned on
Considering the documentation says it was deprecated in 5.3.0, just kill it off.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--20cf307c9ff207e6fd04a859d2f6
Content-Type: text/plain; charset=ISO-8859-1personally I'm of the opinion that even 5.4 should actually cause a fatal
error, but I know this not going to happen5.4 throw an E_DEPRECATED, but with this being rolled into E_ALL, it still
might get ignored
5.4.1 set default to off
5.4.4 throw anE_WARNINGor E_FATAL if turned on
Changing behaviors like that in patch versions is not a good idea as it would
certanly break applications which is unacceptable for "patch" release.
Within PHP 5.4.x we should not changes default settings
Hi Folks:
We all want to see Magic Quotes go away. Discussions on this list indicate
several people are concerned with doing this in a safe and orderly
manner. [1][2] To this end, I have posted an RFC at
https://wiki.php.net/rfc/magicquotes_finalePlease read it through, think about it, then post your opinions to the
mailing list.
"Raise E_DEPRECATED when running the CGI or any web server SAPI and a
php.ini file does not contain “magic_quotes_gpc = Off”."
and
"Raise E_ERROR when running the CGI or any web server SAPI and a php.ini
file does not contain “magic_quotes_gpc = Off”."
Doesn't that mean that anybody not running a php.ini file will just
always get this warning/error? I wouldn't want that as a php.ini file
should be optional.
cheers,
Derick
Derick Rethans wrote:
"Raise
E_DEPRECATEDwhen running the CGI or any web server SAPI and a
php.ini file does not contain “magic_quotes_gpc = Off”."and
"Raise
E_ERRORwhen running the CGI or any web server SAPI and a php.ini
file does not contain “magic_quotes_gpc = Off”."Doesn't that mean that anybody not running a php.ini file will just
always get this warning/error? I wouldn't want that as a php.ini file
should be optional.cheers,
Derick
That's also a big concern for me. PHP should not fail if one
configuration line
is missing from the file.
Am 19.07.2011 00:46, schrieb Ángel González:
Derick Rethans wrote:
"Raise
E_DEPRECATEDwhen running the CGI or any web server SAPI and a
php.ini file does not contain “magic_quotes_gpc = Off”."and
"Raise
E_ERRORwhen running the CGI or any web server SAPI and a php.ini
file does not contain “magic_quotes_gpc = Off”."Doesn't that mean that anybody not running a php.ini file will just
always get this warning/error? I wouldn't want that as a php.ini file
should be optional.cheers,
Derick
That's also a big concern for me. PHP should not fail if one configuration line
is missing from the file.
since this is default OFF there is no warning if not configured
empty php.ini implicits = Off
Am 19.07.2011 00:46, schrieb Ángel González:
Derick Rethans wrote:
"Raise
E_DEPRECATEDwhen running the CGI or any web server SAPI and a
php.ini file does not contain “magic_quotes_gpc = Off”."and
"Raise
E_ERRORwhen running the CGI or any web server SAPI and a php.ini
file does not contain “magic_quotes_gpc = Off”."Doesn't that mean that anybody not running a php.ini file will just
always get this warning/error? I wouldn't want that as a php.ini file
should be optional.cheers,
Derick
That's also a big concern for me. PHP should not fail if one configuration line
is missing from the file.since this is default OFF there is no warning if not configured
empty php.ini implicits = Off
sadly no:
tyrael@thor:~/checkouts$ php -n -r 'echo PHP_VERSION."\n";echo
ini_get("magic_quotes_gpc")."\n";'
5.3.6-6~dotdeb.1
1
tyrael@chronos:~/checkouts/php/src/php/php-src/branches/PHP_5_4$
./sapi/cli/php -n -r 'echo PHP_VERSION."\n";echo
ini_get("magic_quotes_gpc")."\n";'
5.4.0alpha2-dev
1
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Am 19.07.2011 01:12, schrieb Ferenc Kovacs:
since this is default OFF there is no warning if not configured
empty php.ini implicits = Offsadly no:
tyrael@thor:~/checkouts$ php -n -r 'echo PHP_VERSION."\n";echo
ini_get("magic_quotes_gpc")."\n";'
5.3.6-6~dotdeb.1
1tyrael@chronos:~/checkouts/php/src/php/php-src/branches/PHP_5_4$
./sapi/cli/php -n -r 'echo PHP_VERSION."\n";echo
ini_get("magic_quotes_gpc")."\n";'
5.4.0alpha2-dev
1
i expect if someone is writing the code to deprecate a feature
he well also set it's default to 0 - what now is set does
not interest
Am 19.07.2011 01:12, schrieb Ferenc Kovacs:
since this is default OFF there is no warning if not configured
empty php.ini implicits = Offsadly no:
tyrael@thor:~/checkouts$ php -n -r 'echo PHP_VERSION."\n";echo
ini_get("magic_quotes_gpc")."\n";'
5.3.6-6~dotdeb.1
1tyrael@chronos:~/checkouts/php/src/php/php-src/branches/PHP_5_4$
./sapi/cli/php -n -r 'echo PHP_VERSION."\n";echo
ini_get("magic_quotes_gpc")."\n";'
5.4.0alpha2-dev
1i expect if someone is writing the code to deprecate a feature
he well also set it's default to 0 - what now is set does
not interest
magic_quotes_gpc is deprecated as of 5.3
http://php.net/manual/en/migration53.deprecated.php
only the default values was left to 1
I also expected this to be changed to 0, but it seems it isn't a clear
cut as Stas expressed in the 5.4 vote thread that the defaults
shouldn't be used anyway.
but my whole point for this was that
"since this is default OFF there is no warning if not configured
empty php.ini implicits = Off"
isn't true. if you omit a configuration option from your php.ini not
Off, but the default will be used, which is currently On for the
magic_quotes_gpc, and it isn't 100% sure that we will change the
default, of course I think we should set it to the same values as we
use for the php.ini-production.
sor I think that the original idea "Raise E_DEPRECATED when running
the CGI or any web server SAPI and a php.ini file does not contain
“magic_quotes_gpc = Off" would be a bad idea, I agree with Ángel: PHP
should not fail if one configuration line is missing from the file.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
-------- Original-Nachricht --------
Betreff: Re: [PHP-DEV] [RFC] Magic Quotes in PHP, the Finalle
Datum: Tue, 19 Jul 2011 09:07:51 +0200
Von: Ferenc Kovacs tyra3l@gmail.com
An: Reindl Harald h.reindl@thelounge.net
CC: internals@lists.php.net
magic_quotes_gpc is deprecated as of 5.3
http://php.net/manual/en/migration53.deprecated.php
only the default values was left to 1
how dumb is this?
if i deprecate something i do not like to use it in
future and at the same time i enable it as default?
there is no logical reason
Reindl Harald wrote:
magic_quotes_gpc is deprecated as of 5.3
http://php.net/manual/en/migration53.deprecated.php
only the default values was left to 1how dumb is this?
if i deprecate something i do not like to use it in
future and at the same time i enable it as default?there is no logical reason
Actually it is perfectly logical when one looks at 'BC'.
It may not have been the correct choice in hindsight, but it was implemented at
a time when PHP6 was on the road map, and that is no longer the case. The
problem now is to 'wean' older sites without breaking too much as has happened
in the past. I've just been asked to look at another perfectly functional site
which is built on 'old practices' but which will not run on PHP5.2 even ... at
least we also have control of the version of PHP running it. On hosted sites
that just automatically update these 'little changes' can cause major upheaval?
PHP5.3 is still only slowly rolling out in the hosted world, and those changes
result in extra work for people who perhaps don't even know that there has been
a change?
--
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//
Firebird - http://www.firebirdsql.org/index.php
Am 19.07.2011 10:41, schrieb Lester Caine:
Reindl Harald wrote:
magic_quotes_gpc is deprecated as of 5.3
http://php.net/manual/en/migration53.deprecated.php
only the default values was left to 1how dumb is this?
if i deprecate something i do not like to use it in
future and at the same time i enable it as default?there is no logical reason
Actually it is perfectly logical when one looks at 'BC'.
It may not have been the correct choice in hindsight, but it was implemented
at a time when PHP6 was on the road map, and that is no longer the case.
does not matter
anybody who maintains a server should make a explicit config
and not relying on random defaults
[PHP]
zend.ze1_compatibility_mode = 0
zend.enable_gc = 1
register_globals = 0
register_argc_argv = 0
register_long_arrays = 0
always_populate_raw_post_data = 0
upload_tmp_dir = "/var/www/uploadtemp"
open_basedir = "/www:/usr/share/pear:/usr/share/php"
include_path = ".:/www/phpincludes:/usr/share/pear:/usr/share/php"
tidy.default_config = "/etc/php/tidy.conf"
error_log = "syslog"
mime_magic.magicfile = "/etc/php/magic.mime"
crack.default_dictionary = "/www/phpincludes/cracklib-words"
zlib.output_compression = 0
zlib.output_compression_level = 8
safe_mode = 0
max_execution_time = 120
max_input_time = 120
memory_limit = "256M"
post_max_size = "60M"
upload_max_filesize = "60M"
file_uploads = 1
max_file_uploads = 30
allow_url_fopen = 1
allow_url_include = 0
realpath_cache_size = 512K
realpath_cache_ttl = 120
error_reporting = E_ALL | E_STRICT
docref_root = "http://at.php.net/manual/de/";
docref_ext = ".php"
disable_functions = "exec, passthru, shell_exec, system, proc_open, proc_close, proc_nice,
proc_terminate, proc_get_status, pcntl_exec, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid,
posix_setsid, posix_setuid, mail, symlink"
disable_classes = ""
engine = 1
short_open_tag = 1
asp_tags = 0
y2k_compliance = 1
output_buffering = 0
output_handler = ""
implicit_flush = 0
allow_call_time_pass_reference = 0
safe_mode_gid = 0
safe_mode_allowed_env_vars = "PHP_"
safe_mode_protected_env_vars = "LD_LIBRARY_PATH"
expose_php = 0
display_errors = 0
display_startup_errors = 1
log_errors = 1
log_errors_max_len = 2048
html_errors = 1
track_errors = 0
warn_plus_overloading = 1
enable_dl = 0
cgi.force_redirect = 0
cgi.rfc2616_headers = 0
fastcgi.impersonate = 1
ignore_repeated_errors = 0
ignore_repeated_source = 0
arg_separator.output = "&"
arg_separator.input = "&"
variables_order = "EGPCS"
gpc_order = "GPC"
magic_quotes_gpc = 0
magic_quotes_runtime = 0
magic_quotes_sybase = 0
default_mimetype = "text/html"
default_socket_timeout = 10
auto_detect_line_endings = 0
unserialize_callback_func = ""
precision = 14
serialize_precision = 17
highlight.string = "#dd0000"
highlight.comment = "#ff8000"
highlight.keyword = "#007700"
highlight.bg = "#ffffff"
highlight.default = "#0000bb"
highlight.html = "#000000"
auto_prepend_file = ""
auto_append_file = ""
extension = "gd.so"
extension = "mbstring.so"
extension = "mcrypt.so"
extension = "mysqli.so"
extension = "mysql.so"
extension = "tidy.so"
extension = "fileinfo.so"
extension = "eaccelerator.so"
extension = "suhosin.so"
[Session]
session.save_path = "/var/www/sessiondata"
session.save_handler = "files"
session.use_cookies = 1
session.use_only_cookies = 1
session.name = "PHPSESSID"
session.referer_check = ""
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = "/"
session.cookie_domain = ""
session.cookie_secure = 0
session.cookie_httponly = 0
session.serialize_handler = "php"
session.gc_probability = 1
session.gc_divisor = 200
session.gc_maxlifetime = 2700
session.entropy_file = "/dev/urandom"
session.entropy_length = 32
session.cache_limiter = "nocache"
session.cache_expire = 180
session.use_trans_sid = 0
session.bug_compat_42 = 0
session.bug_compat_warn = 0
session.hash_function = 1
session.hash_bits_per_character = 6
url_rewriter.tags = "disabled"
[MySQL]
mysql.default_host = "localhost"
mysql.default_port = 3306
mysql.default_socket = "/var/lib/mysql/mysql.sock"
mysql.allow_local_infile = 0
mysql.default_user = ""
mysql.default_password = ""
mysql.connect_timeout = 30
mysql.allow_persistent = 0
mysql.max_persistent = 0
mysql.max_links = 15
mysql.trace_mode = 0
[MySQLI]
mysqli.default_host = "localhost"
mysqli.default_port = 3306
mysqli.default_socket = "/var/lib/mysql/mysql.sock"
mysqli.allow_local_infile = 0;
mysqli.default_user = ""
mysqli.default_password = ""
mysqli.allow_persistent = 0
mysqli.max_persistent = 0
mysqli.max_links = 15
mysqli.reconnect = 1
[mysqlnd]
mysqlnd.collect_statistics = 0
mysqlnd.collect_memory_statistics = 0
mysqlnd.debug = 0
mysqlnd.net_read_timeout = 60
mysqlnd.net_read_buffer_size = 131072
[Assertion]
assert.active = 1
assert.warning = 1
assert.bail = 0
assert.callback = ""
assert.quiet_eval = 0
[Sockets]
sockets.use_system_read = 1
[com]
com.allow_dcom = 1
com.autoregister_typelib = 1
com.autoregister_casesensitive = 1
com.autoregister_verbose = 1
[bcmath]
bcmath.scale = 20
[soap]
soap.wsdl_cache_enabled = 1
soap.wsdl_cache_dir = "/var/www/uploadtemp"
soap.wsdl_cache_ttl = 86400
[mbstring]
mbstring.language = "German"
mbstring.internal_encoding = "ISO-8859-1"
mbstring.http_input = "auto"
mbstring.encoding_translation = 0
mbstring.detect_order = "auto"
mbstring.func_overload = 0
[Date]
date.timezone = "Europe/Vienna"
[browscap]
browscap = "/etc/php/browscap.ini"
[mail function]
SMTP = "mail.thelounge.net"
sendmail_from = "lounge-mailer mailer@thelounge.net"
smtp_port = 25
[eaccelerator]
eaccelerator.cache_dir = "/var/cache/eaccelerator"
eaccelerator.allowed_admin_path = "/www/thelounge.net/default/eaccelerator/";
eaccelerator.log_file = "/www/_logs/apache_eaccelerator.log"
eaccelerator.enable = 1
eaccelerator.check_mtime = 1
eaccelerator.check_mtime_interval = 20
eaccelerator.optimizer = 1
eaccelerator.debug = 0
eaccelerator.filter = ""
eaccelerator.shm_size = 350
eaccelerator.shm_max = 350M
eaccelerator.shm_ttl = 1800
eaccelerator.shm_prune_period = 900
eaccelerator.shm_only = 0
eaccelerator.compress = 1
eaccelerator.compress_level = 5
[suhosin]
suhosin.get.max_vars = 50
suhosin.post.max_vars = 300
suhosin.post.max_value_length = 260000
suhosin.request.max_vars = 300
suhosin.request.max_value_length = 260000
suhosin.log.file = 511
suhosin.log.file.name = "/www/_logs/php_error.log"
suhosin.log.use-x-forwarded-for = Off
suhosin.upload.max_uploads = 30
suhosin.executor.func.blacklist = "exec, passthru, shell_exec, system, proc_open, proc_close, proc_nice,
proc_terminate, proc_get_status, pcntl_exec, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid,
posix_setsid, posix_setuid, mail, symlink"
suhosin.executor.disable_emodifier = Off
suhosin.session.encrypt = Off
anybody who maintains a server should make a explicit config
and not relying on random defaults
Consider me told. Amazed that a 2 year old deprecation notice is still
outstanding, but told all the same.
I think, rather than having "production" and "development", we need
"best practise". And these ini files only contain the things needed to
alter the default settings.
Currently, the production and development ini files cover ALL the
settings. Consider what has been said about the shared hosters - they
don't read stuff to help themselves. They simply install, choose a ini
file (maybe) and they're done. Having it so that they have to read ini
files, release notes, etc. ... well, fast buck === short cut
somewhere.
If there was an approved "best practice" INI file which only covered
the changes to the defaults, this would be a fast win for PHP in that
we can say that this really is all you need to know about how PHP has
moved on in the defaults department. Sure, we used to use magic
quotes. Now we don't. Best practice would specifically imply potential
BC. Exactly because the position has changed. So, any errors due to an
ini setting in the "best practice" file is a big warning straight
away.
As it stands :
A - Some of the defaults don't get altered anywhere. The defaults work
and are carried through to the INI files, making the entries in the
INI files redundant and possibly dangerous if PHP then changes the
defaults.
B - Some of the defaults are overriden based upon environment. That's
also fine but if the values are changed in both production and
development, then the default is wrong and should be changed to match
what is currently being used in the INI filles
I suppose it is all about trying to keep the most people happy. The
bleeding-edge want safe, secure and fast runtime where the defaults
are right and the minimum amount of changes is needed to tune to the
environment (sapi and extension mainly I'd say). The hosters want the
least number of support issues - so bugger security, let's keep all
those bad practices and ini settings.
I think a minimal php.ini-best-practice would certainly highlight this
to the hosters.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
Reindl Harald wrote:
magic_quotes_gpc is deprecated as of 5.3
http://php.net/manual/en/migration53.deprecated.php
only the default values was left to 1how dumb is this?
if i deprecate something i do not like to use it in
future and at the same time i enable it as default?there is no logical reason
Actually it is perfectly logical when one looks at 'BC'.
It may not have been the correct choice in hindsight, but it was implemented
at a time when PHP6 was on the road map, and that is no longer the case.
does not matteranybody who maintains a server should make a explicit config
and not relying on random defaults
Fine if you actually have ACCESS to the ini file !!!!
If you are on a service where access is not available, and the settings change
breaking your site ...
The point I was trying to make is that simply switching something off that
running and currently functional code expects to be on - because that is how
they are provided with the service currently - is what needs managing. Hopefully
we are not going back to the days when things were simply broken without
warning, such as happened when PHP5.1 was pushed out ...
It is more about managing the change than simply removing magic quotes? The
history of that proposed change is relevant since it highlights why some perhaps
now incorrect choices were made, but simply reverting a choice needs to be
documented properly.
Perhaps what I am looking for is some notes somewhere to direct people to WHEN
their sites stop working as they have been for many years? Yes I know it's not
the developers problem, but just as the change from PHP4, there is a LOT of
legacy code that someone will need to change, and where people have made that
change, their input would be helpful to others?
--
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//
Firebird - http://www.firebirdsql.org/index.php
Am 19.07.2011 12:20, schrieb Lester Caine:
Reindl Harald wrote:
magic_quotes_gpc is deprecated as of 5.3
http://php.net/manual/en/migration53.deprecated.php
only the default values was left to 1how dumb is this?
if i deprecate something i do not like to use it in
future and at the same time i enable it as default?there is no logical reason
Actually it is perfectly logical when one looks at 'BC'.
It may not have been the correct choice in hindsight, but it was implemented
at a time when PHP6 was on the road map, and that is no longer the case.
does not matteranybody who maintains a server should make a explicit config
and not relying on random defaultsFine if you actually have ACCESS to the ini file !!!!
If you are on a service where access is not available, and the settings
change breaking your site ...
whoever has access to the ini-file maintains the machine and
dumb administrators can not be a reason fro deprecate something
and leave it enabled by default
yes i know that their are many server admins with simply missing
knowledges, but maybe some people should learn that a webspace
with some hundret MB and a hughe feature-list is not possible
for 5 US$ per month if they need any quality of service
May I ask you guys to stay on topic?
I posted the steps to remove it. There are only two open questions
about the warning level for the setter (or to kill them) and that's
all. Everything else is off topic. Please don't hijack this thread any
longer :)
Am 19.07.2011 12:20, schrieb Lester Caine:
Reindl Harald wrote:
magic_quotes_gpc is deprecated as of 5.3
http://php.net/manual/en/migration53.deprecated.php
only the default values was left to 1how dumb is this?
if i deprecate something i do not like to use it in
future and at the same time i enable it as default?there is no logical reason
Actually it is perfectly logical when one looks at 'BC'.
It may not have been the correct choice in hindsight, but it was implemented
at a time when PHP6 was on the road map, and that is no longer the case.
does not matteranybody who maintains a server should make a explicit config
and not relying on random defaultsFine if you actually have ACCESS to the ini file !!!!
If you are on a service where access is not available, and the settings
change breaking your site ...whoever has access to the ini-file maintains the machine and
dumb administrators can not be a reason fro deprecate something
and leave it enabled by defaultyes i know that their are many server admins with simply missing
knowledges, but maybe some people should learn that a webspace
with some hundret MB and a hughe feature-list is not possible
for 5 US$ per month if they need any quality of service
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
well
ON TOPIC:
deprecate it, throw a warning and set default to off
if you can not set default to off for whatever reason
you can not deprecate it - so simple the things are
Am 19.07.2011 12:31, schrieb Pierre Joye:
May I ask you guys to stay on topic?
I posted the steps to remove it. There are only two open questions
about the warning level for the setter (or to kill them) and that's
all. Everything else is off topic. Please don't hijack this thread any
longer :)Am 19.07.2011 12:20, schrieb Lester Caine:
Reindl Harald wrote:
magic_quotes_gpc is deprecated as of 5.3
http://php.net/manual/en/migration53.deprecated.php
only the default values was left to 1how dumb is this?
if i deprecate something i do not like to use it in
future and at the same time i enable it as default?there is no logical reason
Actually it is perfectly logical when one looks at 'BC'.
It may not have been the correct choice in hindsight, but it was implemented
at a time when PHP6 was on the road map, and that is no longer the case.
does not matteranybody who maintains a server should make a explicit config
and not relying on random defaultsFine if you actually have ACCESS to the ini file !!!!
If you are on a service where access is not available, and the settings
change breaking your site ...whoever has access to the ini-file maintains the machine and
dumb administrators can not be a reason fro deprecate something
and leave it enabled by defaultyes i know that their are many server admins with simply missing
knowledges, but maybe some people should learn that a webspace
with some hundret MB and a hughe feature-list is not possible
for 5 US$ per month if they need any quality of service
--
Mit besten Grüßen, Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / software-development / cms-solutions
p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40
icq: 154546673, http://www.thelounge.net/
Hello.
I have only one question - is really that many old applications able
to run on 5.3 who require magic_quotes, safe mode, register globals
and other legacy stuff?
How long are you planing on keeping the BC? 10 years, 15 years? Maybe 20?
Reality is - break it in 5.4 or in 6.0 in two-three years - the whine
will be the same. Even if you do it in 7.0 - people will whine a lot.
Some really stupid assholes still are writing new applications who
relly on magic_quotes and safe mode - does that mean now we have to
keep the BC for other 10 years?
Stuff is depricated, it emits a ton of warnings. If people do
development with turned off deprication warnings - it's their own
problem, not the developers. You have warned them in the best way you
can - if they choose to ignore that warning - it's not your problem.
The language should move on. PHP now is at a point when it is ready to
get rid of that old crap stuff and be more shiny and far better than a
few years ago. At least russian speaking community is very aware of
the deprecation and waits anxiously when they are removed physically.
Personally I do not even remember when I last worked on a project
using any of the deprecated stuff. Even some old projects do not rely
on any of these. I and all my fellow developers I know just decline
the clients who have old legacy projects and don't invest in upgrading
their apps, because no one wants to have anything to do with that (or
we just tell the client that we will bill them 5x - no one agreed yet
;) )
I think the development should move on and deprecated stuff just has
to be removed period. We, user-land developers, will deal with the
rest of the problem - it's our job ;)
Hi Derick:
Doesn't that mean that anybody not running a php.ini file will just
always get this warning/error? I wouldn't want that as a php.ini file
should be optional.
Yeah, that's problematic. What are your thoughts as to how we should
move forward regarding Magic Quotes?
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
On Tue, Jul 19, 2011 at 5:26 PM, Daniel Convissor
danielc@analysisandsolutions.com wrote:
Hi Derick:
Doesn't that mean that anybody not running a php.ini file will just
always get this warning/error? I wouldn't want that as a php.ini file
should be optional.Yeah, that's problematic. What are your thoughts as to how we should
move forward regarding Magic Quotes?
I do not want to sound harsh but could you please read my reply? It
defines how it should be done. The only questions are about the
warning level when one called set*, as we should not remove it. a set
disabling the mq should however not raise a warning. Deprecation
warnings are already in place.
But the rfc you proposed is definitively not a good thing to do
(breakage in patch releases, too many warnings, etc.).
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi Pierre:
I do not want to sound harsh but could you please read my reply?
I had read your reply. I value your opinion. I also want to hear from
other people, and Derick in particular, which is why I directly addressed
him in my prior email to the list.
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
hi,
if there are no objection until then, I will commit this patch as it
is tomorrow.
Thanks for your feedback!
On Wed, Jul 20, 2011 at 1:52 PM, Daniel Convissor
danielc@analysisandsolutions.com wrote:
Hi Pierre:
I do not want to sound harsh but could you please read my reply?
I had read your reply. I value your opinion. I also want to hear from
other people, and Derick in particular, which is why I directly addressed
him in my prior email to the list.Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi Pierre:
if there are no objection until then, I will commit this patch as it
is tomorrow.
Derick is out of town until Monday.
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
and? I'm not sure the reason why you insist on getting his voice. This
topic has been discussed over and over and if, and I really mean if,
there are objections about the warning level, we can always change it
later.
On Fri, Jul 22, 2011 at 2:11 AM, Daniel Convissor
danielc@analysisandsolutions.com wrote:
Hi Pierre:
if there are no objection until then, I will commit this patch as it
is tomorrow.Derick is out of town until Monday.
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi Folks:
We all want to see Magic Quotes go away. Discussions on this list indicate
several people are concerned with doing this in a safe and orderly
manner. [1][2] To this end, I have posted an RFC at
https://wiki.php.net/rfc/magicquotes_finalePlease read it through, think about it, then post your opinions to the
mailing list.
I'm not sure about the version change cycle (5.4 vs 5.5 vs 6.0), but regarding
this part of the RFC:
"'removal' What do people think should happen here? Please discuss."
That's a key point as it's not a simple matter, especially considering several
functions and settings exist. I reckon we all now agree that get_magic_quotes_*()
should remain but return false. But for example, what about people who use
set_magic_quotes_runtime() and set it to false? Should we punish these people
for the sake of a cleaner break from our beloved magic quotes? Maybe. I think
the current patch would simply remove it. Where is the current patch, and what
does it do?
Regards,
Philip
hi Daniel,
What is wrong with the solution we came in the past to kill them? It
covers everything this RFC is trying to define and in a cleaner way.
Cleaner as in not being noisy in all possible ways.
As far as I can remember, it was something along these lines:
- GPC beeing killed means they are off, always. That also means that
the default is Off too. - a warning is raised when one tries to call
set_magic_quotes_runtime(true); That's the only new warning introduce
by this removal. - get_magic_quotes_gpc and get_magic_quotes_runtime always returns
false, without any warning, notices, etc.
Cheers,
On Mon, Jul 18, 2011 at 4:39 PM, Daniel Convissor
danielc@analysisandsolutions.com wrote:
Hi Folks:
We all want to see Magic Quotes go away. Discussions on this list indicate
several people are concerned with doing this in a safe and orderly
manner. [1][2] To this end, I have posted an RFC at
https://wiki.php.net/rfc/magicquotes_finalePlease read it through, think about it, then post your opinions to the
mailing list.Thanks,
--Dan
[1] "Vote results" http://marc.info/?t=131089383200001&r=1&w=2
[2] "5.4 features vote" http://marc.info/?t=131019327500001&r=1&w=2--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
As far as I can remember, it was something along these lines:
- GPC beeing killed means they are off, always. That also means that
the default is Off too.- a warning is raised when one tries to call
set_magic_quotes_runtime(true); That's the only new warning introduce
by this removal.- get_magic_quotes_gpc and get_magic_quotes_runtime always returns
false, without any warning, notices, etc.
I completely agree with this. Let's just get the short, sharp shock over
with and kill MQ in 5.4: that's what the majority voted for.
Adam