Yes, that's a possible workaround, though it's not very convenient

Yes, I think the dependent input should always be cleared

Please report any bugs found to the related Phab project https://phabricator.wikimedia.org/project/view/6132/ ( the extension page on mediawiki.org was also updated to include a link to the project )

@Aklapper yup, sorry! absolutely, I have just shut the https://github.com/vedmaka/SemanticQueryInterface/issues down

@Aklapper please use Phab :) thanks!

The fields that actually store the IP addresses are the acr_ip / acd_ip and both are varbinary(255) so I assume there are no issues with the length right now.

The service probably could be drafted like below:

It feels like the User::getTalkPage could be also migrated into a new service, but probably not the TalkPageNotificationManger

Probably the TalkPageNotificationManager need to be introduced before the WatchlistNotificationManager (T208777) because as I understand it the User::clearNotification is to be replaced by the WatchlistNotificationManager and the method make use of both User::getNewtalk and User:: setNewtalk so it would make sense to have these already moved to the service

probably checkNewtalk needs to be factored out too

Great, thanks!

Oh, I see, I am glad we've found it! @Urfiner could you please verify your PF version too?

@Anysite that's true, but the point is that PageForms code actually do wait for VEForAll to complete all the work and only then actually submits the form [1]

@Urfiner can I ask you to verify your PageForms version and commit one more time?
@Anysite could you please share your PageForms and VEForAll version too?

@kostajh ah, I've got it, thanks! That makes it clear and at the same time makes things worse - at first glance, I don't see any good solution to make this patch compatible with every extension ( see https://phabricator.wikimedia.org/T224607#5224443 ) since the change seems to be simply way too radical.

@kostajh @daniel I am a bit confused about how this could result in broken CI, could you give me some clues on what did go wrong?

In T224607#5222255, @Umherirrender wrote:

MediaWikiTestCase::setGroupPermissions should override the services, not each extension calling that function or at least mention the fact, that it is needed.

Since the related change was merged, do you think we should track this task as Resolved?

Also kind of experiencing this on Ubuntu 18, PHP 7.3 - ended commenting out both tests otherwise it just freezes my machine after running it for about an hour

I experience the same problem on Windows 7, PHP 7.3.3 NTS, 24755f024fe4efeab9f56a56073f75fc2ae3d7da of mediawiki/core - WfShellExecTest::testT69870 and CommandTest::testT69870 are running infinitely blocking other tests from being run

Also getting same Cannot use MediaWiki\Revision\SlotRecord as SlotRecord because the name is already in use in... error on PHP 7.0.9 when trying to install REL1_32 from git

@MGChecker @Liuxinyu970226 Yup, it was included into ConfirmEdit but it's also good ( at least it was ) to have a simpler captcha-only version. Still, I'd really like it to be upgraded eventually ( especially taking into account that reCaptcha 3 was released already by google ), but unfortunately I don't have enough time for it right now

@Aklapper: yep - https://www.mediawiki.org/wiki/Extension:ReCaptcha

This feature will really help a lot to the ones who maintain wiki-farms or have wikis on separate subdomains as multi-language solution.