Page MenuHomePhabricator

Add a hook to modify $wgLogTypes / LogPage::validTypes() at runtime
Open, LowPublic


Some extensions conditionally register log types based on configuration. Instead of forcing them to resort to an extension function (or always register the log type), we should have a hook point for this. It would probably go in LogPage::validTypes().

Related: T180192: Audit wgExtensionFunctions, onRegistration and onSetupAfterCache callbacks in Wikimedia-deployed extensions.

Event Timeline

Extensions that could use this: Interwiki, Translate, CommentStreams, OAuth, QuizGame

kchapman added a project: good first task.
kchapman moved this task from Next to Later on the Platform Team Legacy board.
Florian added a subscriber: Florian.

Let's see if a student wants to take this, I'll mentor it :)

Hello, @Florian - I am interested in this task. And I have tried doing it assuming that the log type is always the same as the extension name as I noticed from interwiki extension

interwikiHook.PNG (254×805 px, 16 KB)

interwikiJson.PNG (59×256 px, 1 KB)

, but I have a problem and I hope you can help me.

I made some changes in two files: LogPage.php and GlobalFunctions.php

starting with GlobalFunctions I added the following script to get the extension name from its JSON file, and I added this script in wfLoadExtension function as each extension is passing through it and it can access every extension path easily and dynamically

wfloadextension.PNG (257×631 px, 19 KB)

it should return the extension name and it does `I tested it through print_r()'
then it should add this log type into $wgLogTypes[] array by the following function -and that is where I think the problem is-

addextensionlogtype.PNG (385×608 px, 13 KB)

as it adds the new log types but they do not look as expected

logsPage.PNG (625×800 px, 20 KB)

could you please help me figure out what went wrong?
thanks in advance.

@AdhamKhatean Thanks for taking a look into it and trying to solve this task! :)

To your problem you describe: It does look like it looks, as it's a message key, which does not resolve to an actual message (meaning, that the key is not in the translation file of the current or fallback language). MediaWiki then renders the translation as a string you see (basically the message key).

However, taking a look at your overall solution: I'm not sure, if you understood the task correctly: What you did, from my point of view, is automatically registering a log-type for each extension. This is problematic for at least two reasons:

  • Not nearly every extension requires a log type, so we would start registering log types without any real reason
  • The log type is then still not being registered conditionally, that's, however, the point of this task

So, instead of doing this automatic registration of a log type (which, btw., can have a different name than the extension, some extension even has multiple different log types, AbuseFilter has two for example), I would go with the solution proposed in the task description: Provide a hook. A MediaWiki hook allows an extension to run code on a specific point in time during the execution of MediaWiki code, to, e.g., register additional things like log types or change the behavior of a specific functionality. You can take a look here to get more general information about hooks.

Hope that helps you finding a solution for this problem, I would really like to get this fixed :) Once you've a change ready, it would also make sense to upload it as a change to our code-review system, gerrit. This allows me (and other fellow developers) to take a look at your changes and give you advise on the exact line, without the need to look at pictures of code :)

@Florian - I also felt like I am going in the wrong direction So, I posted here. But, now thanks to you I think I have an idea about what I should do. :)
I will keep you update, and next time I will upload the patch directly to Gerrit instead of writing here. excuse me for taking screenshots and posting here, this OpenSource experience is kinda new to me.

I will continue working on this idea

Change 583123 had a related patch set uploaded (by AdhamKhatean; owner: AdhamKhatean):
[mediawiki/core@master] add a hook to modify $wgLogTypes

Change 583124 had a related patch set uploaded (by AdhamKhatean; owner: AdhamKhatean):
[mediawiki/core@master] add a hook to modify $wgLogTypes at LogPage

Change 583124 abandoned by AdhamKhatean:
add a hook to modify $wgLogTypes at LogPage

Change 583123 abandoned by AdhamKhatean:
add a hook to modify $wgLogTypes

Change 583123 restored by AdhamKhatean:
add a hook to modify $wgLogTypes

Change 583123 abandoned by AdhamKhatean:
add a hook to modify $wgLogTypes

Change 583596 had a related patch set uploaded (by AdhamKhatean; owner: AdhamKhatean):
[mediawiki/core@master] add extension log-Type(s) to valid log types

@AdhamKhatean: Hi, do you plan to fix the patch in ? Asking as you are set as task assignee. Thanks!

@AdhamKhatean: I am resetting the assignee of this task because there has not been progress lately (please correct me if I am wrong!). Resetting the assignee avoids the impression that somebody is already working on this task. It also allows others to potentially work towards fixing this task. Please claim this task again when you plan to work on it (via Add Action...Assign / Claim in the dropdown menu) - it would be welcome. Thanks for your understanding!