Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #6958 > unrolled thread

Never log deprecation warnings

Back to article view | Back to comp.lang.php

Contents

  Never log deprecation warnings Jonathan Stein <jstein@image.dk> - 2012-09-06 11:51 +0200
    Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-06 09:10 -0400
      Re: Never log deprecation warnings Jonathan Stein <jstein@image.dk> - 2012-09-06 15:42 +0200
        Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-06 11:26 -0400
    Re: Never log deprecation warnings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-06 15:48 +0200
      Re: Never log deprecation warnings "J.O. Aho" <user@example.net> - 2012-09-06 18:04 +0200
        Re: Never log deprecation warnings The Natural Philosopher <tnp@invalid.invalid> - 2012-09-06 17:33 +0100
          Re: Never log deprecation warnings Scott Johnson <noonehome@chalupasworld.com> - 2012-09-06 10:37 -0700
            Re: Never log deprecation warnings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-06 19:49 +0200
              Re: Never log deprecation warnings The Natural Philosopher <tnp@invalid.invalid> - 2012-09-06 18:56 +0100
                Re: Never log deprecation warnings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-06 21:53 +0200
          Re: Never log deprecation warnings "J.O. Aho" <user@example.net> - 2012-09-06 20:41 +0200
            Re: Never log deprecation warnings The Natural Philosopher <tnp@invalid.invalid> - 2012-09-06 19:52 +0100
    Re: Never log deprecation warnings Denis McMahon <denismfmcmahon@gmail.com> - 2012-09-06 19:59 +0000
      Re: Never log deprecation warnings The Natural Philosopher <tnp@invalid.invalid> - 2012-09-06 23:34 +0100
    Re: Never log deprecation warnings Jonathan Stein <jstein@image.dk> - 2012-09-07 00:53 +0200
      Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-06 20:09 -0400
      Re: Never log deprecation warnings Scott Johnson <noonehome@chalupasworld.com> - 2012-09-06 18:41 -0700
        Re: Never log deprecation warnings Jonathan Stein <jstein@image.dk> - 2012-09-10 12:43 +0200
          Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-10 07:43 -0400
            Re: Never log deprecation warnings Jonathan Stein <jstein@image.dk> - 2012-09-11 10:38 +0200
              Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-11 08:34 -0400
                Re: Never log deprecation warnings Jonathan Stein <jstein@image.dk> - 2012-09-11 15:06 +0200
                  Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-11 09:32 -0400
                    Re: Never log deprecation warnings Jonathan Stein <jstein@image.dk> - 2012-09-11 21:53 +0200
                      Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-11 16:16 -0400
                        Re: Never log deprecation warnings Jonathan Stein <jstein@image.dk> - 2012-09-13 11:31 +0200
                          Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-13 13:01 -0400
                            Re: Never log deprecation warnings Jonathan Stein <jstein@image.dk> - 2012-09-13 21:33 +0200
                              Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-13 20:08 -0400
                                Re: Never log deprecation warnings Michael Fesser <netizen@gmx.de> - 2012-09-14 15:41 +0200
                      Re: Never log deprecation warnings Christoph Becker <cmbecker69@gmx.de> - 2012-09-12 02:28 +0200
                        Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-11 21:08 -0400
              Re: Never log deprecation warnings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-12 01:16 +0200
                Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-11 20:18 -0400
                  Re: Never log deprecation warnings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-12 12:09 +0200
                    Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-12 08:26 -0400
                      Re: Never log deprecation warnings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-12 15:42 +0200
                        Re: Never log deprecation warnings The Natural Philosopher <tnp@invalid.invalid> - 2012-09-12 15:07 +0100
                        Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-12 12:08 -0400
                          Re: Never log deprecation warnings Shake <QUITAESTO@QUITAESTO.NOES> - 2012-09-12 18:13 +0200
                            Re: Never log deprecation warnings The Natural Philosopher <tnp@invalid.invalid> - 2012-09-12 17:28 +0100
                              Re: Never log deprecation warnings Shake <QUITAESTO@QUITAESTO.NOES> - 2012-09-12 18:37 +0200
                            Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-12 15:01 -0400
                              Re: Never log deprecation warnings Anders Wegge Keller <wegge@wegge.dk> - 2012-09-12 21:35 +0200
                                Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-13 12:53 -0400
                              Re: Never log deprecation warnings Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-09-12 21:39 +0200
                                Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-13 12:55 -0400
                                  Re: Never log deprecation warnings Shake <QUITAESTO@QUITAESTO.NOES> - 2012-09-13 19:24 +0200
                                    Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-13 15:02 -0400
                                      Re: Never log deprecation warnings Shake <QUITAESTO@QUITAESTO.NOES> - 2012-09-13 21:12 +0200
                                        Re: Never log deprecation warnings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-13 22:20 +0200
                                          Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-13 20:13 -0400
                                        Re: Never log deprecation warnings Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-13 20:10 -0400
                              Re: Never log deprecation warnings Tim Streater <timstreater@greenbee.net> - 2012-09-12 23:13 +0100

Page 1 of 3  [1] 2 3  Next page →

#6958 — Never log deprecation warnings

Hi.

Does anyone have an idea about how to never log deprecation warnings - 
even if the code alters error_reporting?

I'm thinking about setting "php_flag log_errors off" in .htaccess to 
block all error logging, but I would prefer to log real errors.

(And no, avoiding deprecated functions is not an option in this case).

   Regards

     Jonathan

[toc] | [next] | [standalone]

#6960

On 9/6/2012 5:51 AM, Jonathan Stein wrote:
> Hi.
>
> Does anyone have an idea about how to never log deprecation warnings -
> even if the code alters error_reporting?
>
> I'm thinking about setting "php_flag log_errors off" in .htaccess to
> block all error logging, but I would prefer to log real errors.
>
> (And no, avoiding deprecated functions is not an option in this case).
>
>    Regards
>
>      Jonathan

Get rid of the code causing the deprecated warnings.

They're there for a reason.  If you ignore them now, your code will 
break when you (or your host) upgrades PHP and the functions you're 
using are no longer supported.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6961

On 06-09-2012 15:10, Jerry Stuckle wrote:

>> (And no, avoiding deprecated functions is not an option in this case).
>
> Get rid of the code causing the deprecated warnings.

I think you missed something...

   Regards

     Jonathan

[toc] | [prev] | [next] | [standalone]

#6963

On 9/6/2012 9:42 AM, Jonathan Stein wrote:
> On 06-09-2012 15:10, Jerry Stuckle wrote:
>
>>> (And no, avoiding deprecated functions is not an option in this case).
>>
>> Get rid of the code causing the deprecated warnings.
>
> I think you missed something...
>
>    Regards
>
>      Jonathan
>

No, I didn't miss anything.  You are missing the point.  The warnings 
are there for a reason.  You will HAVE TO CHANGE THE CODE SOONER OR LATER!

Better to change it now when your site isn't down because of an update 
to PHP.  Ignoring the problem WILL NOT MAKE IT GO AWAY.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6962

Jonathan Stein wrote:

> Does anyone have an idea about how to never log deprecation warnings -
> even if the code alters error_reporting?
> 
> I'm thinking about setting "php_flag log_errors off" in .htaccess to
> block all error logging, but I would prefer to log real errors.

You could set `error_reporting' to something that includes `& ~DEPRECATED' 
(and code that alters error-reporting in more than one place, except for 
debugging purposes, is potentially bad code anyway), but …
 
> (And no, avoiding deprecated functions is not an option in this case).

… I strongly suggest you fix the code instead.  Why is that IYHO not an 
option in this case?

If you do not fix deprecated code now, it will be a real error in one of the 
next PHP versions.  Upgrading PHP to that version will cause your 
application to break.  Not upgrading to it will cause your application to be 
inherently insecure as you would not get all the security fixes.  You do not 
want any of that to happen.


PointedEars
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)

[toc] | [prev] | [next] | [standalone]

#6964

On 06/09/12 15:48, Thomas 'PointedEars' Lahn wrote:
> Jonathan Stein wrote:
>
>> Does anyone have an idea about how to never log deprecation warnings -
>> even if the code alters error_reporting?
>>
>> I'm thinking about setting "php_flag log_errors off" in .htaccess to
>> block all error logging, but I would prefer to log real errors.
>
> You could set `error_reporting' to something that includes `& ~DEPRECATED'
> (and code that alters error-reporting in more than one place, except for
> debugging purposes, is potentially bad code anyway), but …
>
>> (And no, avoiding deprecated functions is not an option in this case).
>
> … I strongly suggest you fix the code instead.  Why is that IYHO not an
> option in this case?
>
> If you do not fix deprecated code now, it will be a real error in one of the
> next PHP versions.  Upgrading PHP to that version will cause your
> application to break.  Not upgrading to it will cause your application to be
> inherently insecure as you would not get all the security fixes.  You do not
> want any of that to happen.

Of course they could try to stick to the current version of PHP on the 
server, but of course then they will be stuck with all the security 
issues which may be in the PHP (we seen a number of such this year) or 
try to bakcport fixes to the PHP source code and build it.

Of course the absolute simplest thing to do is to fix the PHP scripts, 
have to agree with Thomas and Jerry on this one.

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#6965

J.O. Aho wrote:
> On 06/09/12 15:48, Thomas 'PointedEars' Lahn wrote:
>> Jonathan Stein wrote:
>>
>>> Does anyone have an idea about how to never log deprecation warnings -
>>> even if the code alters error_reporting?
>>>
>>> I'm thinking about setting "php_flag log_errors off" in .htaccess to
>>> block all error logging, but I would prefer to log real errors.
>>
>> You could set `error_reporting' to something that includes `& 
>> ~DEPRECATED'
>> (and code that alters error-reporting in more than one place, except for
>> debugging purposes, is potentially bad code anyway), but …
>>
>>> (And no, avoiding deprecated functions is not an option in this case).
>>
>> … I strongly suggest you fix the code instead.  Why is that IYHO not an
>> option in this case?
>>
>> If you do not fix deprecated code now, it will be a real error in one 
>> of the
>> next PHP versions.  Upgrading PHP to that version will cause your
>> application to break.  Not upgrading to it will cause your application 
>> to be
>> inherently insecure as you would not get all the security fixes.  You 
>> do not
>> want any of that to happen.
> 
> Of course they could try to stick to the current version of PHP on the 
> server, but of course then they will be stuck with all the security 
> issues which may be in the PHP (we seen a number of such this year) or 
> try to bakcport fixes to the PHP source code and build it.
> 
> Of course the absolute simplest thing to do is to fix the PHP scripts, 
> have to agree with Thomas and Jerry on this one.
> 
yeah. One day I'll have to plough through mine and replace all the

if ($_POST[....) with
if (isset($_POST[...) && $_POST[...))

and lower the error logs by a couple of hundred bytes a day.

But meanwhile I think I'll make myself a coffee and a cheese sandwich.


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#6966

On 9/6/2012 9:33 AM, The Natural Philosopher wrote:
> J.O. Aho wrote:
>> On 06/09/12 15:48, Thomas 'PointedEars' Lahn wrote:
>>> Jonathan Stein wrote:
>>>
>>>> Does anyone have an idea about how to never log deprecation warnings -
>>>> even if the code alters error_reporting?
>>>>
>>>> I'm thinking about setting "php_flag log_errors off" in .htaccess to
>>>> block all error logging, but I would prefer to log real errors.
>>>
>>> You could set `error_reporting' to something that includes `&
>>> ~DEPRECATED'
>>> (and code that alters error-reporting in more than one place, except for
>>> debugging purposes, is potentially bad code anyway), but …
>>>
>>>> (And no, avoiding deprecated functions is not an option in this case).
>>>
>>> … I strongly suggest you fix the code instead.  Why is that IYHO not an
>>> option in this case?
>>>
>>> If you do not fix deprecated code now, it will be a real error in one
>>> of the
>>> next PHP versions.  Upgrading PHP to that version will cause your
>>> application to break.  Not upgrading to it will cause your
>>> application to be
>>> inherently insecure as you would not get all the security fixes.  You
>>> do not
>>> want any of that to happen.
>>
>> Of course they could try to stick to the current version of PHP on the
>> server, but of course then they will be stuck with all the security
>> issues which may be in the PHP (we seen a number of such this year) or
>> try to bakcport fixes to the PHP source code and build it.
>>
>> Of course the absolute simplest thing to do is to fix the PHP scripts,
>> have to agree with Thomas and Jerry on this one.
>>
> yeah. One day I'll have to plough through mine and replace all the
>
> if ($_POST[....) with
> if (isset($_POST[...) && $_POST[...))
>
> and lower the error logs by a couple of hundred bytes a day.
>
> But meanwhile I think I'll make myself a coffee and a cheese sandwich.
>
>

2 sugars and cream for me please.

[toc] | [prev] | [next] | [standalone]

#6967

Scott Johnson wrote:

> On 9/6/2012 9:33 AM, The Natural Philosopher wrote:
>> J.O. Aho wrote:
>>> Of course the absolute simplest thing to do is to fix the PHP scripts,
>>> have to agree with Thomas and Jerry on this one.
>>
>> yeah. One day I'll have to plough through mine and replace all the
>>
>> if ($_POST[....) with
>> if (isset($_POST[...) && $_POST[...))
>>
>> and lower the error logs by a couple of hundred bytes a day.
>>
>> But meanwhile I think I'll make myself a coffee and a cheese sandwich.
> 
> 2 sugars and cream for me please.

JFTR: Those are _not_ the kind of warnings the OP was talking about.  The 
ones he means are caused by calls such as split(…), and are probably much 
larger in number.  See for example <http://php.net/split> (DEPRECATED in 
favor of <http://php.net/preg_split>).


PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#6968

Thomas 'PointedEars' Lahn wrote:
> Scott Johnson wrote:
> 
>> On 9/6/2012 9:33 AM, The Natural Philosopher wrote:
>>> J.O. Aho wrote:
>>>> Of course the absolute simplest thing to do is to fix the PHP scripts,
>>>> have to agree with Thomas and Jerry on this one.
>>> yeah. One day I'll have to plough through mine and replace all the
>>>
>>> if ($_POST[....) with
>>> if (isset($_POST[...) && $_POST[...))
>>>
>>> and lower the error logs by a couple of hundred bytes a day.
>>>
>>> But meanwhile I think I'll make myself a coffee and a cheese sandwich.
>> 2 sugars and cream for me please.
> 
> JFTR: Those are _not_ the kind of warnings the OP was talking about.  The 
> ones he means are caused by calls such as split(…), and are probably much 
> larger in number.  See for example <http://php.net/split> (DEPRECATED in 
> favor of <http://php.net/preg_split>).
> 
> 

Thats when you write your OWN split() that calls preg_split()



> PointedEars


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#6971

The Natural Philosopher wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Scott Johnson wrote:
>>> On 9/6/2012 9:33 AM, The Natural Philosopher wrote:
>>>> J.O. Aho wrote:
>>>>> Of course the absolute simplest thing to do is to fix the PHP scripts,
>>>>> have to agree with Thomas and Jerry on this one.
>>>> yeah. One day I'll have to plough through mine and replace all the
>>>>
>>>> if ($_POST[....) with
>>>> if (isset($_POST[...) && $_POST[...))
>>>>
>>>> and lower the error logs by a couple of hundred bytes a day.
>>>>
>>>> But meanwhile I think I'll make myself a coffee and a cheese sandwich.
>>> 2 sugars and cream for me please.
>> 
>> JFTR: Those are _not_ the kind of warnings the OP was talking about.  The
>> ones he means are caused by calls such as split(…), and are probably much
>> larger in number.  See for example <http://php.net/split> (DEPRECATED in
>> favor of <http://php.net/preg_split>).
> 
> Thats when you write your OWN split() that calls preg_split()

Surprise me.


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

[toc] | [prev] | [next] | [standalone]

#6969

On 06/09/12 18:33, The Natural Philosopher wrote:

> yeah. One day I'll have to plough through mine and replace all the
>
> if ($_POST[....) with
> if (isset($_POST[...) && $_POST[...))
>
> and lower the error logs by a couple of hundred bytes a day.
>
> But meanwhile I think I'll make myself a coffee and a cheese sandwich.

That's why there is sed, you get your coffee break and get it fixed :D

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#6970

J.O. Aho wrote:
> On 06/09/12 18:33, The Natural Philosopher wrote:
> 
>> yeah. One day I'll have to plough through mine and replace all the
>>
>> if ($_POST[....) with
>> if (isset($_POST[...) && $_POST[...))
>>
>> and lower the error logs by a couple of hundred bytes a day.
>>
>> But meanwhile I think I'll make myself a coffee and a cheese sandwich.
> 
> That's why there is sed, you get your coffee break and get it fixed :D
> 
Having first spent two days trying to work out what the exact syntax of 
the regexp needed to be, and then a week following correcting all the 
places it replaced something that didnt want to be replaced.

WRWLWA

(When running well, leave well alone)


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#6972

On Thu, 06 Sep 2012 11:51:56 +0200, Jonathan Stein wrote:

> And no, avoiding deprecated functions is not an option in this case.

At some future point, either you're going to be running on a horribly 
outdated, unsupported, unpatched php with script kiddies worldwide 
exploiting your vulnerabilities (if you control your php version), or the 
website is going to break when whoever controls your php version (ie the 
hosting provider) upgrades to a version that no longer has the functions 
that you're currently getting deprecation warnings for (if you don't 
control the php version).

Personally I'd consider both of these futures sub optimal, and that 
fixing the code to use whatever functions replace the deprecated ones was 
better.

Better to fix it now in a controlled manner before the functions are 
removed completely, rather than later in a panic because the website is 
down.

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#6973

Denis McMahon wrote:
> On Thu, 06 Sep 2012 11:51:56 +0200, Jonathan Stein wrote:
> 
>> And no, avoiding deprecated functions is not an option in this case.
> 
> At some future point, either you're going to be running on a horribly 
> outdated, unsupported, unpatched php with script kiddies worldwide 
> exploiting your vulnerabilities (if you control your php version), or the 
> website is going to break when whoever controls your php version (ie the 
> hosting provider) upgrades to a version that no longer has the functions 
> that you're currently getting deprecation warnings for (if you don't 
> control the php version).
> 
> Personally I'd consider both of these futures sub optimal, and that 
> fixing the code to use whatever functions replace the deprecated ones was 
> better.
> 
> Better to fix it now in a controlled manner before the functions are 
> removed completely, rather than later in a panic because the website is 
> down.
> 
> Rgds
> 
> Denis McMahon

This is of course how one set of developers keep another set in work

Keep on upgrading and forcing source code changes on the bastards!



-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#6974

On 06-09-2012 11:51, Jonathan Stein wrote:

> (And no, avoiding deprecated functions is not an option in this case).

Thank you all for your replies, but when I wrote that avoiding 
deprecated functions is not an option, I actually meant it. ;-)

This is some old code, that we keep on-line for historic reasons as long 
as we can do it with a minimum of effort.
When we can no longer do it safely, the sites may rest in peace.

   Regards

     Jonathan

[toc] | [prev] | [next] | [standalone]

#6975

On 9/6/2012 6:53 PM, Jonathan Stein wrote:
> On 06-09-2012 11:51, Jonathan Stein wrote:
>
>> (And no, avoiding deprecated functions is not an option in this case).
>
> Thank you all for your replies, but when I wrote that avoiding
> deprecated functions is not an option, I actually meant it. ;-)
>
> This is some old code, that we keep on-line for historic reasons as long
> as we can do it with a minimum of effort.
> When we can no longer do it safely, the sites may rest in peace.
>
>    Regards
>
>      Jonathan
>

Then your site WILL BREAK.  It's only a matter of time.

There is NO EXCUSE for rewriting bad code now, when it is not a matter 
of "life and death" - which it will be later.

It's your choice.  Pay a little now, or pay A LOT later.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6976

On 9/6/2012 3:53 PM, Jonathan Stein wrote:
> On 06-09-2012 11:51, Jonathan Stein wrote:
>
>> (And no, avoiding deprecated functions is not an option in this case).
>
> Thank you all for your replies, but when I wrote that avoiding
> deprecated functions is not an option, I actually meant it. ;-)
>
> This is some old code, that we keep on-line for historic reasons as long
> as we can do it with a minimum of effort.
> When we can no longer do it safely, the sites may rest in peace.
>
>    Regards
>
>      Jonathan
>

I personally do not have an answer however beyond what has already been 
given.
Can I ask why if the site is so not important and only kept for 
historical purposes, why the logging the deprecated functions is an 
issue. I am just curious.

Scotty

[toc] | [prev] | [next] | [standalone]

#6997

Den 07-09-2012 03:41, Scott Johnson skrev:

> Can I ask why if the site is so not important and only kept for
> historical purposes, why the logging the deprecated functions is an
> issue. I am just curious.

They take up space (even though the sites are not used much by real 
users, search engines keep indexing them).

- And the warnings are just noise in the logs when we know that we're 
not going to react on them.

   Regards

     Jonathan

[toc] | [prev] | [next] | [standalone]

#6998

On 9/10/2012 6:43 AM, Jonathan Stein wrote:
> Den 07-09-2012 03:41, Scott Johnson skrev:
>
>> Can I ask why if the site is so not important and only kept for
>> historical purposes, why the logging the deprecated functions is an
>> issue. I am just curious.
>
> They take up space (even though the sites are not used much by real
> users, search engines keep indexing them).
>
> - And the warnings are just noise in the logs when we know that we're
> not going to react on them.
>
>    Regards
>
>      Jonathan
>

And your site WILL BREAK.  To not fix them is the ultimate in stupidity.

If the site isn't that important, then just why not just take it down 
now instead of waiting for it to crash hard?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.php

csiph-web