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().
|Open||None||T271574 Replace $wgExtensionFunctions with a hook|
|Open||None||T180192 Audit wgExtensionFunction, onRegistration and onSetupAfterCache callbacks in Wikimedia-deployed extensions|
|Open||None||T200385 Add a hook to modify $wgLogTypes / LogPage::validTypes() at runtime|
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
, 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
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-
as it adds the new log types but they do not look as expected
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
@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!