[TYPO3-core] RFC #14729: Backwards compatibility brocken by disabled deprecation log

Thomas Allmer at at delusionworld.com
Wed Jun 16 13:05:34 CEST 2010


On 15.06.2010 20:54, Ingo Renner wrote:
> I see it like this: You and all the admins out there are responsible for
> turning off deprecation log in production environments. We as the core
> team are responsible to not let people run into unexpected crashes we
> can avoid.

I see it like this: TYPO3 should work out of the box when installed. It 
should be as fast as possible and should not generate unneeded stuff.

Why generate a deprecated log if the admin using this TYPO3 version 
can't use it? maybe he doesn't have the knowledge or the time to look at 
it closely. I mean updating foreign extension is "hard" and won't help 
you anything if it's not published to the TER by its author.

Why make it harder for regular admins? Most of them already struggle 
when installing TYPO3; why do they need to take care of disabling the 
deprecation log?

As said before when installing it should work as good as it gets. For 
developers it's clearly great to have the deprecation log so they can 
get rid of deprecated functions, but I guess a lot of admins don't have 
the knowlege or the time to actually do that. The deprecation log 
doesn't help them at all it just makes TYPO3 for them slower.

just my 2 cents

PS: it also can harm - just had a case where a too big deprecation log 
file crashed php all the time with fancy error messages. It was hard to 
track down and made me think why is it enabled by default?
-- 
+---------------------------------+-----------------------------------+
| Thomas Allmer                   |   http://www.delusionworld.com    |
| E-mail: at at delusionworld.com    |   phone: +43 699 16217064         |
+---------------------------------+-----------------------------------+


More information about the TYPO3-team-core mailing list