Can database Logger write to watchdog, in addition to ultimate_cron_log?

We had an issue with the latest patch,

In our case, the strings from RfcLogLevel::getLevels() were translated, which resulted in a Call to undefined method Drupal\Core\Logger\LoggerChannel::***()

I fixed this in the latest patch and also added the comment suggestion from #10

      // A severity of -1 is not a valid RfcLogLevel but is the default value. With -1,
      // Ultimate Cron logs a message saying that cron has been executed, which is
      // unnecessary if you're running cron every minute as recommended.
      if ($log_entry->severity > -1) {
        $severityLevels = RfcLogLevel::getLevels();
        $severity = strtolower($severityLevels[$log_entry->severity]->getUntranslatedString());
        $this->loggerFactory->get('ultimate_cron_' . $log_entry->name)->{$severity}($log_entry->message ?: $log_entry->formatInitMessage());
      }

For anyone curious, because there was no interdiff between 8 and 11, (aside from the comment addition) the change from #11 amounts to this:

-        $severity = strtolower($severityLevels[$log_entry->severity]);
+        $severity = strtolower($severityLevels[$log_entry->severity]->getUntranslatedString());

Makes sense.

This is one of important functionality which is missing in ultimate cron.
Shared path in #11 is working for me, Thanks @jOpdebeeck for sharing it.

I don't think it is necessary to uses a separate channel for every job, that could be part of the message.

watchdog messages are translatable, they must not contain dynamic parts or every unique message will be its own separate translatable string. This could also be a security issue.

Instead, formatInitMessage() needs to be re-implemented to use placeholders.

Not convinced that this should be built into the Database logger. Either it should be it's own logger plugin (but then you can't have both I guess) or a separate setting.

Hi everyone,

Will it have sense to use general `log` method instead of calling method from variable? Less code + Less magic in the code = Easier to read.

I also think that from logs searching perspective logs should be placed in the old channel and not in a new one. If log comes from a module it should be written into the modules channel and not into a new one.

      // A severity of -1 is not a valid RfcLogLevel but is the default value. With -1,
      // Ultimate Cron logs a message saying that cron has been executed, which is
      // unnecessary if you're running cron every minute as recommended.
      if ($log_entry->severity > -1) {
        $log_message = strip_tags($log_entry->message ?: $log_entry->formatInitMessage());
        $this
          ->loggerFactory
          ->get($log_entry->name)
          ->log($log_entry->severity, $log_message);
      }

I have added strip_tags in my example to convert such error messages:

LogicException: Tratata in super_duper_cron() (line 44 of

To this:

LogicException: Tratata in super_duper_cron() (line 44 of /var/www/html/web/modules/custom/my_module/my_module.module).

I created a MR with the latest patch and the suggestions of @devdits.

watchdog messages are translatable, they must not contain dynamic parts or every unique message will be its own separate translatable string. This could also be a security issue.

Looks like it was decided in 🐛 LogEntry causes erroneous records in "locales_source" table Needs review to not translate log messages, so using FormattableMarkup should be enough.

Not sure if anything else needs to happen here.

I reviewed the merge request, it is working for me. Now errors are also visible in watchdog log. Which was a major issue before.