[TYPO3-core] Strategy for deprecation log

[Jost Baron]

Hi!

I hope its ok to post here, even though I'm not a core team member.

On 04/03/2013 01:28 PM, JoH asenau wrote:
>
>>> A fresh install is of course in dev mode. But the visual sign should be
>>> so obvious that no client accepts it when the site is launched.
>>
>> This is very developer-centric point of view. Why? I would say a fresh
>> install is in production mode! Fast and without any nasty warnings,
>> debug error messages, etc. It's clean and people can just "use it"!
>>
>> If someone wants to debug some extension, is planning to upgrade, or has
>> some trouble and needs more logging, he knows what he's doing (or will
>> ask some developer friend or the community) and can then enable the
>> "developer-mode".
>>
>> Let's try to make TYPO3 simple for the average user!
>
> +1
>
> actually it should be +10 ;-)
>
> Many average users don't even know about the deprecation log being
> active by default.
> After a while they run into problems due to the logfile being too big
> for the available disk space of their shared hosting environment.
>
> One example: I've seen huge deprecation logs even with a native
> introduction package due to some of the extension using a deprecated
> way to provide their icons.
>
> Cheers
>
> Joey
>

I also think that dev mode is not a good idea. If someone needs such a
mode, he can create a TS constant to switch it on and off. That way,
other functionality (switch CSS/JS compression on or off, etc.) could
easily be done too.


To improve the deprecation log functionality, I suggest this:

Deprecation logging is by default restricted to the last call of a
deprecated function. That info (That a deprecated function has recently
been called and where to find more info) is shown at some place, but
only if that last call isn't too old. The place to show this message
could be the reports module, or maybe somewhere where it is always
visible in the backend, depending on the level of annoyance wanted.

There are options (preferrably in TS) to deactivate that message and/or
switch full logging on.


This way, an integrator is annoyed with deprecation messages, but if he
does not switch them off, nothing really bad happens (maybe some small
performance penalty). And if the messages are displayed prominently
enough, he'll not forget to switch them off (which IMO is the main
reason for big deprecation logs). Or, even better, he'll take action and
solve the problems indicated by the message. Also, the full deprecation
logging functionality doesn't need to be changed, so it is not that much
work to do.

Regards,
Jost