Page MenuHomePhabricator

Remove the benefits block from Special:CreateAccount
Closed, ResolvedPublic3 Estimated Story Points

Description

User story:

As a newcomer creating my first account, I want the account creation form to be simple and free of distractions, so that I can focus on the one thing I came to do: complete my registration.

In other words: remove the benefits block (mw-createacct-benefits-container) from Special:CreateAccount

Parent epic:
T429029: [EPIC] Move Account Creation Form Changes from GrowthExperiments to MediaWiki Core

Background

The benefits block (the panel showing project statistics alongside the account creation form) was hidden as part of Account Creation Experiments on mobile (as part of the 1.8.3). Results showed that simplifying the form improved registration completion considerably.

image.png (2,378×1,464 px, 518 KB)

We then ran a desktop experiment (WE1.8 FY25/26) to confirm "Benefits Block" removal is safe there as well (T430785: Learn whether the benefits block has a large effect on Special:CreateAccount on desktop, results: T433291: Publish experiment results for "Account Creation: No Benefits on desktop" (WE1.8 FY25/26)).

Task

Remove the benefits block and all supporting code:

  • Remove the benefits block rendering from Special:CreateAccount on all platforms and skins
  • Remove the components, templates, styles, and i18n messages used only by the benefits block
  • Remove any configuration flags / experiment instrumentation specific to the benefits block
  • Remove or update any tests that cover the benefits block
  • Check for and remove dead references (hooks, feature flags, docs) left behind

Acceptance criteria

  • Special:CreateAccount renders without the benefits block on desktop and mobile, across supported skins
  • No benefits-block code, styles, messages, or config remain in the codebase
  • Account creation works end to end

Event Timeline

This is not ready for Tech News yet, so I'm not adding tags, but here's a potential draft when we are ready:

The [[Special:CreateAccount]] page is being simplified as part of ongoing work to modernize the account creation experience. The panel showing project statistics will no longer appear next to the form on desktop and mobile web. Multiple account creation experiments show that a simpler form helps newcomers complete registration. (T433783)

KStoller-WMF raised the priority of this task from Medium to High.Tue, Aug 4, 9:50 PM
DMburugu set the point value for this task to 3.

Change #1318698 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/core@master] CreateAccount: deprecate SpecialCreateAccountBenefitsHook

https://gerrit.wikimedia.org/r/1318698

Change #1318699 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/core@master] CreateAccount: drop benefits block

https://gerrit.wikimedia.org/r/1318699

Change #1318703 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/GrowthExperiments@master] feat: remove integration with SpecialCreateAccountBenefitsHook

https://gerrit.wikimedia.org/r/1318703

Change #1325527 had a related patch set uploaded (by Michael Große; author: Michael Große):

[operations/mediawiki-config@master] Growth: Drop now unused config for benefits block

https://gerrit.wikimedia.org/r/1325527

Change #1325530 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/WikimediaEvents@master] refactor: clean up the old account creation experiments

https://gerrit.wikimedia.org/r/1325530

Change #1318703 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] feat: remove integration with SpecialCreateAccountBenefitsHook

https://gerrit.wikimedia.org/r/1318703

Change #1318698 merged by jenkins-bot:

[mediawiki/core@master] CreateAccount: deprecate SpecialCreateAccountBenefitsHook

https://gerrit.wikimedia.org/r/1318698

Change #1325530 merged by jenkins-bot:

[mediawiki/extensions/WikimediaEvents@master] refactor: clean up the old account creation experiments

https://gerrit.wikimedia.org/r/1325530

Change #1318699 merged by jenkins-bot:

[mediawiki/core@master] CreateAccount: drop benefits block

https://gerrit.wikimedia.org/r/1318699

This needs to wait until the changes that have been merged so far have been successfully deployed with the train. I have scheduled the associated config change for the Monday, August 24 UTC afternoon backport window.

After that has been deployed without incident, this task can be directly resolved.

Tacsipacsi subscribed.

This is not ready for Tech News yet, so I'm not adding tags, but here's a potential draft when we are ready:

The [[Special:CreateAccount]] page is being simplified as part of ongoing work to modernize the account creation experience. The panel showing project statistics will no longer appear next to the form on desktop and mobile web. Multiple account creation experiments show that a simpler form helps newcomers complete registration. (T433783)

With the changes merged on Friday, I think this is now ready to be announced. In fact, since the announcement didn’t make it in today’s Tech News, next week’s issue should be past/present simple tense rather than future, i.e. “The panel showing project statistics no longer appears” instead of “The panel showing project statistics will no longer appear”.

@KStoller-WMF please see thread and confirm if this should be posted.

This is not ready for Tech News yet, so I'm not adding tags, but here's a potential draft when we are ready:

The [[Special:CreateAccount]] page is being simplified as part of ongoing work to modernize the account creation experience. The panel showing project statistics will no longer appear next to the form on desktop and mobile web. Multiple account creation experiments show that a simpler form helps newcomers complete registration. (T433783)

With the changes merged on Friday, I think this is now ready to be announced. In fact, since the announcement didn’t make it in today’s Tech News, next week’s issue should be past/present simple tense rather than future, i.e. “The panel showing project statistics no longer appears” instead of “The panel showing project statistics will no longer appear”.

Confirmed, this should be announced.

Change #1325527 merged by jenkins-bot:

[operations/mediawiki-config@master] Growth: Drop now unused config for benefits block

https://gerrit.wikimedia.org/r/1325527

Mentioned in SAL (#wikimedia-operations) [2026-08-24T13:09:01Z] <lucaswerkmeister-wmde@deploy1003> Started scap sync-world: Backport for [[gerrit:1325527|Growth: Drop now unused config for benefits block (T433783)]], [[gerrit:1328315|arwikiquote: update wordmark (T435505)]]

Mentioned in SAL (#wikimedia-operations) [2026-08-24T13:11:01Z] <lucaswerkmeister-wmde@deploy1003> lucaswerkmeister-wmde, anzx, migr: Backport for [[gerrit:1325527|Growth: Drop now unused config for benefits block (T433783)]], [[gerrit:1328315|arwikiquote: update wordmark (T435505)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-08-24T13:17:35Z] <lucaswerkmeister-wmde@deploy1003> Finished scap sync-world: Backport for [[gerrit:1325527|Growth: Drop now unused config for benefits block (T433783)]], [[gerrit:1328315|arwikiquote: update wordmark (T435505)]] (duration: 08m 33s)

The last config cleanup change has been deployed. Engineering-wise, everything is done here.

Can this be left as a configuration option that can be toggled rather than be removed altogether? I would prefer to keep the benefits block for my wikis CreateAccount page, or alternatively can we see if we can move the benefits block over to the NewSignupPage extension?

It has been already removed altogether. Of course, the source code history is there, so the removal is not irreversible, but I’d say it’s rather unlikely. The extension point (SpecialCreateAccountBenefits hook) has also been deprecated, but I think that deprecation is more likely to be reverted (or replaced with another, more generic hook, e.g. one that runs on more occasions, deferring the decision on when to show anything to the extension) because it gives more freedom in what to show there – the old benefits block was very specific and inflexible, a hook gives much more flexibility while keeping the core code needed to support this flexibility at a minimum.

Can this be left as a configuration option that can be toggled rather than be removed altogether? I would prefer to keep the benefits block for my wikis CreateAccount page, or alternatively can we see if we can move the benefits block over to the NewSignupPage extension?

Our data showed that these stats at best made no difference and at worst were actively harmful. But I can also understand the desire to keep them around in some form or other. This was the commit that removed the logic: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1318699, it can be used as a starting point to move it somewhere else.

As for the hook, more generic ones already exist, for example:

  • SpecialPageBeforeExecute
  • SpecialPageBeforeFormDisplay
  • SpecialPageAfterExecute
  • BeforePageDisplay
  • AuthChangeFormFields

Depending on what exactly is desired, one of these might be suitable.

I do think it is rather uncommon to just rip stuff out because one user (Wikimedia) no longer needs it. There's been a multitude of reasons to add information into the pages and this solution replaced many of such previous cases. Most importantly, 3rd party users might depend on this. Just ripping it out seems inconsiderate and at the VERY least, requires mentioning in the CHANGELOG which wasn't done here either. We are an open source project, we have to take things like this into consideration when modifying the software.

Our data showed that these stats at best made no difference and at worst were actively harmful. But I can also understand the desire to keep them around in some form or other. This was the commit that removed the logic: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1318699, it can be used as a starting point to move it somewhere else.

I would like to know what kind of data is representative of this purported trend, but even then I don't believe Wikimedia as a whole or by the decision of a singular person should make this kind of decision based on a feature that is widely critical to the use of the software, whilst yes the data may not be important enough for Wikimedia to retain, nor is it required for the account creation process, but MediaWiki is not solely used by the Wikimedia Foundation, it is used by far more independent wikis and wiki-farms than it is used within the Wikimedia Foundation's environment.

Also with what @TheDJ has stated above, it definitely needs to be documented if this decision is final, at the very least I also believe that the old hook should not be deprecated, as that way people like myself who would rather keep this implementation can simply reintroduce it as a modification, or re-implementation through a new or current extension. Or alternatively, I believe what @Tacsipacsi has stated is also sufficient.

I would like to know what kind of data is representative of this purported trend

We ran a series of Account Creation experiments over the last several months, and you can also find more detail about the specific V4 Test: “Benefits Block” on Desktop.

This task was not only an effort to simplify the newcomer experience, but also part of a broader effort to simplify and reduce the maintenance burden of our code. I think we sometimes need to make difficult tradeoffs like this in order to support the long-term sustainably of Mediawiki. If we never deprecate features or remove code that is no longer providing enough value, we continually add to the maintenance burden. Over time, this leads to teams spending an increasing share of their capacity fixing bugs and maintaining existing functionality, leaving less capacity for meaningful product improvements, innovation, and adapting to the evolving needs of contributors and the broader internet ecosystem.

I'll admit that I was also on the fence about this particular change, which is why I insisted we run the V4 A/B test before we moved forward with this task. Based on the results, it appeared that removing the benefits block would not only support our longer-term code sustainability goals, but might also have a positive impact on users. So while I understand that this is not a popular change, I still think it was the right one to make.

Just ripping it out seems inconsiderate and at the VERY least, requires mentioning in the CHANGELOG...

I agree that we should make sure changes like this are communicated clearly. The deprecation is being mentioned in the Release Notes for the next release (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1318698/6/RELEASE-NOTES-1.47).

There are other approaches for modifying special pages, including Special:CreateAccount, and as Michael mentions there are many other more generic hooks that can be used.

Given those alternatives, do you think there is a specific use case or capability that is no longer possible with the deprecation that we should consider addressing?

As for the hook, more generic ones already exist, for example:

  • SpecialPageBeforeExecute
  • SpecialPageBeforeFormDisplay
  • SpecialPageAfterExecute
  • BeforePageDisplay
  • AuthChangeFormFields

Depending on what exactly is desired, one of these might be suitable.

  • SpecialPageBeforeExecute runs before any HTML is added, so I don’t see how it could be used.
  • As far as I understand, SpecialPageBeforeFormDisplay doesn’t even run on Special:CreateAccount (it doesn’t extend FormSpecialPage).
  • SpecialPageAfterExecute and BeforePageDisplay could be used, but both have access only to the complete HTML, so they could only add the benefits block using ugly and fragile regular expressions, or by parsing and re-serializing the HTML.
  • AuthChangeFormFields can alter only the form, not stuff next to the form.

So three out of the five hooks don’t allow adding back the block at all, and the other two make it way harder than SpecialCreateAccountBenefits. When I suggested a more generic hook, I didn’t mean that generic; I still think that un-deprecating the existing hook or adding another hook specific to LoginSignupSpecialPage would be a good middle ground: it’d make re-adding the block in an extension much easier while it’d still drop the majority of maintenance burden in core.