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
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
Apr 4 2020
Ok, looking at the status of the opcache after the server startup, it looks like, that the function wfWebStartSetup is present in the cache, like one would expect. However, when WebStart.php is included from index.php or load.php, we evaluate, if a constant named MW_SETUP_CALLBACK is defined already (which is later called in Setup.php, which does not matter for the current case). This constant is, also like expected, not defined when running from index.php or load.php and MediaWiki tries to register the callback function wfWebStartSetup. The problem seems to be, that evaluating this code, MediaWiki defines the function conditionally inside of the defined check for the MW_SETUP_CALLBACK constant. This seems to result in PHP trying to define the wfWebStartSetup function again, even given it is already defined from the preloading run during startup.
Apr 3 2020
This task is probably related to T249248, which could provide a way on how a user could be asked for consent.
but I guess the easier way to implement this it would be for the scripts to be added through CookieWarning itself.
Please also (as an information) do not assign tasks to other people, if they did not explicitly stated that they work on it :) This leaves space for other developers to take up a task they would like to work on and enables assigned developers to manage their tasks, they work on, on their own :)
The idea sounds promising. However, the question would be: How is the extension able to block scripts, that needs to be blocked. I think we're talking about analytics (like Google Analytics) and ad code (like Google AdSense)? How does your wiki add these scripts:
- Is it another extension?
- Is it added through a hook manually (like in LocalSettings.php)?
- Is the code added in the skin/template?
Mar 21 2020
@AdhamKhatean Thanks for taking a look into it and trying to solve this task! :)
Mar 20 2020
Un-assigning myself, as I'm not working on at the moment.
Un-assigning myself, not even sure how I ended up being assigned here in the first place.
Mar 7 2020
Mar 6 2020
Mar 2 2020
Mar 1 2020
Feb 18 2020
Feb 17 2020
Oops, nice to see that this one was resolved, however, there're still links missing:
Feb 15 2020
Feb 13 2020
Thanks to everyone involved in fixing this here, shame on me for not seeing this in the code-re iew :(
Yes, from mean s well, @Ebe123 is a reasonable choice here :)
Feb 12 2020
I'm available for both dates and would be happy to get to know our winner tudents :)
Feb 11 2020
I think we'd the instance count vs. task count in the others years as well, however, especially for tasks with multiple mentors, a mentor may not interact with the task on the platform, but interacted with the student on IRC, Gerrit or phabricator, justd isn't approve the task in GCI (e.g. it turned night in their Timezone or whatever). Last times the task count seemed to be a good compromise between the interaction count and instance count.
Feb 10 2020
Feb 9 2020
Feb 1 2020
The latest master of php (mentioned as 8.0.0-dev) seems to work with preloading MediaWiki, at least it does not segfault anymore, as of now. However, there seems to be some stuff that needs to be investigated, as I currently get a fatal error, that a function in WebStart can not be redeclared:
Jan 24 2020
Just out of curiosity: The default setting for cookies when logging in of MediaWiki should be 30 days. Is it possible that you configured https://www.mediawiki.org/wiki/Manual:$wgCookieExpiration to a way lower amount of time? This would probably the right way to change the default time until a user is logged out.
Jan 20 2020
Sorry, I should've said that: I made the images, as I intended to fix this issue on the local wiki by adding the css property in the timeless.css. That's why you can't actually reproduce this issue on the linked wiki anymore, however it still persists and should (from what I see) not be browser-specific.
Jan 19 2020
@Majavah Yeah, that's what I mean :) Sorry, that I didn't link this in the first place, I didn't think about, that this is probably gerrit-specific and that not everyone might know about this :)
Good catch, didn't see that, sorry for the confusion! I worked on this change to make the tests working again (and bring them back from the broken group). Is it ok for you to work on top of this change? Then your new tests should work as well :)
Jan 18 2020
It's late, but I imported this task into GCI as https://codein.withgoogle.com/dashboard/tasks/4964700098396160/ Let's see if someone claims this in the last days of the contest :)
Jan 17 2020
@Reedy Thanks for checking my assumption :)
@Wolfhelius It would be awesome, however, I would suggest that we move this discussion somewhere else. Either you edit the GoogleLogin documentation on mediawiki.org directly (what I would welcome), or you can point out the improvements on the discussion page.
Jan 16 2020
So, this is resolved or did I miss something? I'm not sure, what we can do in GoogleLogin to mitigate this problem :(