Disable logging options in general site settings and disable plugin System - User Log. Then delete all log files from the administrator/logs
directory.
Now let's play a little with the logging parameters.
administrator/logs
directory.Created everything.php
and joomla_update.php
files, which are mostly identical when updating Joomla.
Created file error.php
that reports an authorization error. In addition, the error is duplicated twice in file everything.php
under the heading INFO and WARNING.
We will get a situation identical to point 2.
Created file deprecated.php
, which is growing before our eyes.
database, databasequery, database-error, deprecated, jerror
in parameter line Log Categories, Log Category Mode -> Include.Created file custom-logging.php
, which mostly contains category deprecated
entries.
======================
Given a fast enough test, I suggest:
If initially the task is to separate all types / categories of logs by files, then I would prefer to have the parameter not Log Almost Everything, but Enable logging and through showon="logging:1"
in XML to regulate the creation of files by category. For example: Log Joomla update, Log outdated API, Log authorization errors, etc.
Obviously, the System - User Log plugin does not work (see points 2 and 3). It must be deleted, the parameter moved to the general settings and the logic "repaired". The plugin was needed BEFORE Joomla 4, until the logging options appeared in the general settings.
The Log Deprecated API parameter requires a description that the parameter generates overhead and should be used with care. I can't judge objectively, but it feels like the site is getting "heavier" and the file size is growing very quickly (literally in a couple of minutes it reached the size of 10 Mb).
Given that there is a corresponding parameter for the outdated API, this category should be removed from the description of the Log Categories parameter (the logs are duplicated in the custom-logging.php
and deprecated.php
files). On the contrary - this parameter should be used to catch quite rare or "unpopular" (so to speak) categories and which will not be included in the list of all logging parameters. Alternatively, it can be implemented as a select, listing all available ones (alas, I don’t know how many there are in total).
In general, I decided to combine all the information in one issue, since there are several suggestions for improvement / correction and implementation may differ. Information for thought.
Labels |
Added:
No Code Attached Yet
|
Labels |
Added:
?
|
Title |
|
I will add for the sake of completeness.
We also have the System - Log Rotation plugin which works well for now. The only thing - the Maximum Logs parameter has lost its relevance, since there are now several files in the log directory, which are formed separately from the plugin.
I would suggest that in the case of the improvements described above, it also makes sense to move the parameters of this plugin to one place with other parameters.