Change the filter in the overview page of the dblog module to a condition object

Thanks, looks good to me as well.

The method addFilterToQuery(Request $request, SelectInterface &$query) needs some documentation updates. The return type is not properly documented.

The wrong return value and type hint for the method DbLogController::addFilterToQuery() has been adressed.

@dagmar & @rajneeshb: Thanks!

Left small comments on the MR

Searching the repo only see about 20 functions that document return void.

Removed the return void from the docblock as requested.

BTW: I get over 20 hits when I do a search for @return void in the code base.

Thanks!

Rest LGTM

I read the IS, comments and the MR. I didn't spot any problems here.

Left a question on the MR

Replied to comment on the PR.

I was a bit worried about the BC break here, but I think most people who are overriding this in 2024 are just going to be using Views instead of writing code that extends the controller.

Another followup could be to refactor away _dblog_get_message_types() and dblog_filters() into OO code somewhere, they look a bit lonely in their individual files.

longwave → closed merge request !9581

The filters in Drupal\migrate\Controller\MigrateMessageController are modeled on the code in the dblog module, so that probably needs to be updated, too. I added 📌 Change the filter in the details page for migration messages to a condition object Active .

I know I am late to the party, but I have a nit with the new code:

  protected function addFilterToQuery(Request $request, SelectInterface &$query): void {

Because of the PHP object model, you almost never have to pass an object by reference.

Automatically closed - issue fixed for 2 weeks with no activity.