User Details
- User Since
- Oct 7 2014, 4:13 AM (468 w, 1 d)
- Availability
- Available
- IRC Nick
- FlorianSW
- LDAP User
- Florianschmidtwelzow
- MediaWiki User
- Florianschmidtwelzow [ Global Accounts ]
May 25 2023
Jan 19 2023
Jan 8 2023
May 14 2022
Feb 25 2022
There seems to be one more thing to consider: My setup right now looks like this:
- mediawiki/core cloned in a directory
- extensions cloned inside /mediawiki/core/extensions
- a composer.local.json, which will be merged into the main composer.json file, with the following contents (stripped away unnecessary things):
"extra": { "merge-plugin": { "include": [ "extensions/*/composer.json" ] } }
Dec 17 2021
Dec 16 2021
Ah, I didn't find this one (looked for property in the search only 🙈). Is it ok for you that I merge both tasks into the linked one and adjust the description/title to cover both? Or would you rather prefer to have them separate? :)
Oct 27 2021
May 14 2021
I wasn't that active in the overall Wikimedia Tech world for the last time, but I would like to throw my hat into the round as well and hope to be able to give some valuable feedback, especially for Community-Projekts (non-WMF deployed) once. Mainly it would be the Google login, CookieWarning and AcceleratedMovilePages (currently on GitHub without CI) extensions. Confirmed it _could_ be interesting, too, however, it's a WMF deployed extension, so might be out-of-door for the beginning (as well as I'm not the only stakeholder).
Apr 26 2021
As this is not an issue with the extension per se and the questions are answered as well, I'm going ahead and close this task :) Feel free to reopen or open a new task if you find a bug or missing feature.
The fact that you need to either:
- have created an account with the GoogleLogin extension (so the link between the Google account and the wiki account is done) _or_
- link the Google account with an existing wiki account through Special:LinkAccounts first _or_
- use the authoritative mode
Apr 25 2021
Jan 7 2021
Just for reference: With change rSMIN557529546e4a: Change default of showing sitenotices to true, this is now the default, so you, @Alaub81, can maybe remove this setting from your LocalSettings.php for a cleaner configuration.
This is most likely a problem with the DismissableSiteNotice extension, rather than MediaWiki-extensions-CookieWarning. CookieWarning was changed to use the sitenotice functionality of MediaWiki, as it is the more correct place where such a notice should be added (see also the discussion in your linked issue). However, DismissableSiteNotice seems to does not work well with the changed styling of the cookieWarning, which, for Vector, is absolutely positioned at the top of the page.
Jan 5 2021
Dec 17 2020
Dec 2 2020
Ok, thx for the info :)
Last changes are +2ed, so this should be fine to be closed :)
Hmm, you're right, didn't see that. Thanks for the patch. Not sure, who should merge the Backport to the release branches, though (may I merge them as well?). Therefore keeping the task open for now.
Dec 1 2020
I'm not quite sure, but this could be done with T254302: Update CookieWarning so it doesn't use the SkinTemplateOutputPageBeforeExec hook resolved?
Nov 26 2020
Nov 22 2020
CookieWarning doesn't use FallbackTemplate from what I can see.
Yep, this is a duplicate of T254302: Update CookieWarning so it doesn't use the SkinTemplateOutputPageBeforeExec hook.
Nov 10 2020
Oct 9 2020
I commented upstream to let ask whether this was intentional and/or whether it will be documented or backported as warning.
Oct 3 2020
One more in Preprocessor_Hash, adding to the task description.
May 13 2020
No, I think it's ok to close this task :-) If we find a good way to test this feature, we can still write a patch or a separate task for it :)
Wouldn't it be more consistent to have a single configuration in ConfirmEdit to configure a proxy? E.g. ReCaptcha would benefit from having a proxy configuration as well, if it is used in such an environment. We could provide an own service (like one for DI) which can be used by Captcha modules in ConfirmEdit to make outbund HTTP requests?
Apr 18 2020
@matmarex I'm not that deep into how VE works, but is there a possibility to have a test from somewhere on this side? Something like a JavaScript testing module, which checks, that the plugin is registered? That would not check the functionality itself, sure, but at least we know, if the plugin is there and _would_ work?
The same probably for reCaptcha as well, right?
Apr 17 2020
Apr 13 2020
Do we really need such a hook? Aren't categories like
- "functional" (which never can be "deactivated")
- "tracking" (like Google Analytics, matomo or whatever tool that tracks the user, probably also EventLogging?)
- "advertising" (like Google AdSense or any other advertisers, which are shipped from external sources)
enough? Especially speaking about how additional categories are described (by a message, e.g.) is probably too much overhead in the first version of such an enhanced consent thingy?
Had the same issue on one of my wikis as well (when trying to delete a user account). Working on it, the solution from T241839: UserMerge cannot create an actor for a usable name that is not an existing user. looks promising, but needs to be done in a way that the extension does that for someone :D