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