Caused by: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/778564

In T298283#7737562, @Reedy wrote:

It looks like config was never included to be merged in, possibly because there wasn't a need for it? - https://github.com/wikimedia/composer-merge-plugin#plugin-configuration

https://github.com/wikimedia/composer-merge-plugin/blob/47be3c0633f981937e4242c442e4faf5711a06e7/src/MergePlugin.php#L52-L57

* By default the "extra" section is not merged. This can be enabled by
* setitng the 'merge-extra' key to true. In normal mode, when the same key is
* found in both the original and the imported extra section, the version in
* the original config is used and the imported version is skipped. If
* 'replace' mode is active, this behaviour changes so the imported version of
* the key is used, replacing the version in the original config.

Maybe "we" need to add a merge-config (like merge-dev/merge-extra/merge-scripts) or similar

Probably worth filing an issue at https://github.com/wikimedia/composer-merge-plugin, we're probably not the only ones with this issue

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"
			]
		}
	}

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? :)

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).

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

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.

In T269178#6665304, @Reedy wrote:

No one has +2d the master patch though :P

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.

In T269173#6665104, @Jdlrobson wrote:

Thanks @Florian for taking care of that one!

I'm not quite sure, but this could be done with T254302: Update CookieWarning so it doesn't use the SkinTemplateOutputPageBeforeExec hook resolved?

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.

I commented upstream to let ask whether this was intentional and/or whether it will be documented or backported as warning.

One more in Preprocessor_Hash, adding to the task description.

Fixed with https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UserMerge/+/588388

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?

@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?

In T249248#6049106, @Skizzerz wrote:

1. A way for extensions to tell CookieWarning what other cookies they are setting which would require consent and which categories they belong to. This is best accomplished by a custom hook imo

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

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.

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 it added by another script on the page (client-side JavaScript)?
• Is the code added in the skin/template?

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

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.

Oops, nice to see that this one was resolved, however, there're still links missing:

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 :)

I'm available for both dates and would be happy to get to know our winner tudents :)

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.