db8ea9c4d535c898cc335cafd966462016a7ed50 removed the code from Campaigns that used to add the loginCTA parameter to the signup link at the bottom of login (and AuthManager would have broken that code anyway); it's useful and should be readded.
Description
Details
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Tgr | T136727 Campaigns should add loginCTA parameter to login->signup link (again) | |||
Resolved | Tgr | T136725 Make login/signup footer customizable by extensions |
Event Timeline
I'm not sure that this really belongs in Campaigns versus adding it from one of the Wikimedia-specific extensions (e.g. WikimediaEvents or WikimediaMessages).
I guess the question is whether we think nearly everyone else who might use Campaigns would care about loginCTA or not.
There seems to be a single non-WMF wiki using the extension and they have 6 users so far so they are probably not making much use of it. So for practical purposes Campaigns is pretty much Wikimedia-specific.
@Tgr, does this mean you're taking on this task? If so, thanks!
For the record, Brad's comment on the mailing list was:
To put the campaign back, someone will have to figure out a good way to let an extension mess with the link in LoginSignupSpecialPage::getAuthForm(). Options include:
- Sticking a new hook in there to mess with the link and/or the HTML.
- Rearranging the code so it's done as an HTMLInfoField instead of being appended as HTML using HTMLForm->addFooterText(), so you can use the existing 'AuthChangeFormFields' hook to mess with it.
Change 302387 had a related patch set uploaded (by Gergő Tisza):
Make login/signup footer available to AuthChangeFormFields hook
Change 302478 had a related patch set uploaded (by Gergő Tisza):
Restore 'loginCTA' campaign name for the signup link at the bottom of login
Change 302387 merged by jenkins-bot:
Make login/signup footer available to AuthChangeFormFields hook
Change 302478 merged by jenkins-bot:
Restore 'loginCTA' campaign name for the signup link at the bottom of login
Well that was overly optimistic, but it's fixed now. Let's check the stats in a week or so to make sure, and then this can be closed off.
mysql:research@analytics-store.eqiad.wmnet [log]> select event_campaign, count(1)/230491*100 pct from ServerSideAccountCreation_5487345 where timestamp > '20170101000000' group by event_campaign having pct > 1 order by pct desc; +---------------------------+---------+ | event_campaign | pct | +---------------------------+---------+ | | 63.2697 | | loginCTA | 29.5274 | | anoneditwarning | 4.4991 | | mobile_watchPageActionCta | 2.6691 | +---------------------------+---------+ 4 rows in set (1.20 sec)
Seems sane.