Last modified: 2014-02-20 02:07:27 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 44628 - Implement ACUX account creation interface in core
Implement ACUX account creation interface in core
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
E3 Experiments (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: spage
https://en.wikipedia.org/wiki/Special...
: tracking
: 43690 (view as bug list)
Depends on: 46305
Blocks: 42630 17576 43816 45313 47801
  Show dependency treegraph
 
Reported: 2013-02-03 21:24 UTC by Isarra
Modified: 2014-02-20 02:07 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Isarra 2013-02-03 21:24:01 UTC
Currently the entire thing is a javascript file. 

For an experiment that's perfectly fine, but this has since been deployed in full on the English Wikipedia and thus that is no longer a viable implementation.

From a user standpoint, anyone without js will miss out on it entirely when much of the visual stuff would still benefit the new folks even without the added responsiveness. 
From a developer standpoint, having the thing implemented in js makes it harder to work with in general as it does not follow interface standards. 
From an i18n standpoint, there is no i18n nor any system messages in general. 
From a wiki admin standpoint, without system messages, the only way to customise things is javascript, but it can be very difficult if not impossible to write on-wiki js that will work with/override system js, which this is.
Comment 1 Steven Walling 2013-02-03 21:48:10 UTC
Agreed about the general point you're making. However, we will be permanently implementing these interface changes in core, not in an extension. It's hard to get more suitable for MediaWiki core than account creation. 

If you want to learn more about these architectural plans before filing bugs, ask in our IRC channel which you're in all the time, check out our Trello board,[1] or Quarterly Planning document.[2]

1. https://trello.com/b/FdtPTV2y
2. https://www.mediawiki.org/wiki/Editor_engagement_experiments/Quarterly_Planning
Comment 2 Isarra 2013-02-03 21:54:28 UTC
If the thing is going in core, then it should not be present in this form as a 'permanent feature' at all. Clarity on these matters where people will actually be looking might help, but in the meantime this is problematic regardless of what documentation there may be.
Comment 3 Isarra 2013-02-03 21:59:10 UTC
To clarify, these things should be implemented BEFORE being deployed in full, not after. This sort of approach just makes things more difficult for everyone.
Comment 4 Steven Walling 2013-02-03 22:23:10 UTC
(In reply to comment #3)
> To clarify, these things should be implemented BEFORE being deployed in full,
> not after. This sort of approach just makes things more difficult for
> everyone.

That's not really your call to make. S and I agreed that turning on the new UI, which was proven through testing to be superior, temporarily while we build a more  permanent version, was better for users than reverting to the ugly, inhumane previous state of English Wikipedia account creation. This was not a full deployment, but rather simply not removing a better experience while we make something more lasting. I stand by that decision.
Comment 5 Isarra 2013-02-03 23:58:32 UTC
Does the English Wikipedia agree with this view?
Comment 6 Ori Livneh 2013-02-04 00:12:44 UTC
(In reply to comment #5)
> Does the English Wikipedia agree with this view?

English Wikipedia is currently having a nice, cold blueberry smoothie. She sends you all her regards.

We're all in agreement. This needs to be re-implemented to merit a permanent roll-out. Give it a rest, already.
Comment 7 Nemo 2013-02-04 00:13:58 UTC
[double mid-air collision]
Isarra, I think what Steven means is that your request is valid, but as a request for account creation internal interface/API in core to be more flexible (or exist at all), making it easier to plug extensions on it.
This is a well known deficiency of MediaWiki, as far as I can understand, see for instance [[mw:Translation_UX/Development_plan#Milestone_SG4:_signup_dialog]].
You may want to create a new bug (or even MW RfC) for this, if one doesn't exist; this would be a duplicate of it. Bug 17312 sort of asks this, I think; I couldn't find another.

This bug can be marked WORKSFORME, INVALID or WONTFIX, but it seems quite sure that this job won't be done as part of this project, so in this component it's probably pointless. You may want to mark it as duplicate of bug 17312 or equivalent, or to move it to core.
Comment 8 Isarra 2013-02-04 01:15:14 UTC
Thank you, Nemo. That actually helps explain a lot.

That said, why is this not part of the project? If the experiments are bringing up valid issues and useful fixes, is there no pipeline to implement them?

I'm not sure what to close this as because LATER is no longer an option and nothing else seems appropriate given the situation - it is a 'bug' that has yet to be resolved; this just isn't the place for it.
Comment 9 MZMcBride 2013-02-04 04:53:45 UTC
(In reply to comment #7)
> Isarra, I think what Steven means is that your request is valid [...]

This request looks valid to me as well. Is there a bug about the general need to re-implement (from JavaScript to PHP) the improved account creation form? If there is no such bug (bug 17312 doesn't appear to be it), isn't this bug valid and unresolved? I'm confused.
Comment 10 Isarra 2013-02-04 05:07:27 UTC
Okay, yeah, this probably is a valid bug, just not under the right component or whatever, if e3 really is just experiments... but I really don't know where it would be appropriate to put this, so could someone who does please fix it?
Comment 11 MZMcBride 2013-02-04 05:08:59 UTC
The "E3 Experiments" component is fine for now. Re-opening.
Comment 12 Steven Walling 2013-02-04 05:14:34 UTC
(In reply to comment #9)
> (In reply to comment #7)
> > Isarra, I think what Steven means is that your request is valid [...]
> 
> This request looks valid to me as well. Is there a bug about the general need
> to re-implement (from JavaScript to PHP) the improved account creation form?
> If
> there is no such bug (bug 17312 doesn't appear to be it), isn't this bug
> valid
> and unresolved? I'm confused.

Part of the reason there is no such bug is because I don't really use Bugzilla to track what the team is actually working on. There are all kinds of outdated and irrelevant bugs floating around components we maintain at any given point in time. I also just find it a little silly to file "bugs" about major product changes like rewriting the core account creation interface. We generally keep our projects tracked on the Trello board I linked above.
Comment 13 Matthew Flaschen 2013-02-04 05:16:27 UTC
"Isarra, I think what Steven means is that your request is valid, but as a
request for account creation internal interface/API in core to be more flexible
(or exist at all), making it easier to plug extensions on it."

No, based on talking to Steven before (and what he said as the first comment), I think he is in agreement that we would to move essentially all of ACUX to core.

There are certainly improvements that can be a made to the core account creation hook points.  But that's not going to be the focus when moving ACUX to core (a significant enough task on its own).

I'm going to change the title to specify core.  As Steven says, we use Trello for some things.  However, it's fine to leave this open as a tracking bug.
Comment 14 Andre Klapper 2013-02-04 17:30:05 UTC
(In reply to comment #12)
> There are all kinds of outdated and irrelevant bugs floating around
> components we maintain at any given point in time.

If you'd like to have some cleanup for your components your welcome to propose it for "Old bugs" as part of https://www.mediawiki.org/wiki/QA/Weekly_goals
Comment 15 MZMcBride 2013-02-12 07:14:13 UTC
Is this bug a duplicate of bug 43690?
Comment 16 Matthew Flaschen 2013-02-12 07:17:49 UTC
Yeah, but this one (though later) is better developed, so I'll mark the other one.
Comment 17 Matthew Flaschen 2013-02-12 07:18:15 UTC
*** Bug 43690 has been marked as a duplicate of this bug. ***
Comment 18 Steven Walling 2013-03-11 17:33:35 UTC
I've removed bug 15700 as a blocker because we're not making separate special pages a hard requirement for our first release. I removed 26751 as a dependency as well, because it was really broad, and we don't plan on moving any functionality except the frontend modifications currently being done in E3Experiments (of course). 

If anyone feels like there are missing requirements, please comment on https://www.mediawiki.org/wiki/Account_creation_user_experience to ask that they be added.
Comment 19 Nemo 2013-03-11 18:04:25 UTC
(In reply to comment #18)
> I've removed bug 15700 as a blocker because we're not making separate special
> pages a hard requirement for our first release. 

Indeed that's not a requirement: the intended blocker was bug 17312, which basically requests code cleanup making enhancements like this possible. (The amount of such cleanup actually needed to fix this bug will be seen later when someone starts working on it, of course.)
Comment 20 Matthew Flaschen 2013-03-11 22:27:51 UTC
This is actually in progress at https://gerrit.wikimedia.org/r/#/c/30637/.  S Page and Munaf Assaf are the primary devs, so I'm assigning S.
Comment 21 Matthew Flaschen 2013-03-19 18:53:05 UTC
This is merged, but not yet in any branches.  It missed the cut for 1.21wmf12, so it will be in 1.21wmf13, cut on April 1.

We should coordinate removing the productized code from ACUX, perhaps leaving just EventLogging for the new form.
Comment 22 Steven Walling 2013-03-19 18:57:43 UTC
(In reply to comment #21)
> This is merged, but not yet in any branches.  It missed the cut for
> 1.21wmf12,
> so it will be in 1.21wmf13, cut on April 1.
> 
> We should coordinate removing the productized code from ACUX, perhaps leaving
> just EventLogging for the new form.

I think probably the easiest thing to do is have us use our normal deploy window before April 1 (so Thursday the 28th) to remove the productized code from ACUX. The testing of the new version will work much better without it, so doing so prior to 1.21wmf13 is a good idea.
Comment 23 Matthew Flaschen 2013-03-19 21:24:44 UTC
Reverted by https://gerrit.wikimedia.org/r/#/c/54713/
Comment 24 MZMcBride 2013-03-19 21:33:54 UTC
I'm lost.

Why was this being implemented with a URL query string and such? I thought the whole idea here was to fix up/improve MediaWiki's core account creation logic, not duplicate it.

I haven't been following most of this closely, but I skimmed <https://gerrit.wikimedia.org/r/30637> and it seems like the entire approach here was wrong. If it's experimental, leave it in an extension. If it's going into core, put it into core. The query string/configurability really doesn't make any sense to me. If you're going to go in that route, why wouldn't Agora be a skin?

And... I thought includes/templates/ was completely deprecated. I thought the only part of the UI that used it was Special:UserLogin and Special:UserLogin?type=signup and they only did so for historical reasons. I could swear there was a bug about killing off these remaining templates (and just leaving NoLocalSettings.php, I guess...). I can't find the bug off-hand, but adding templates like this seems like the wrong approach overall.

Make Agora a MediaWiki skin and/or improve the core account creation interface. If you want to put something behind configuration, just leave it in a MediaWiki extension. Sorry this wasn't flagged earlier.
Comment 25 MZMcBride 2013-03-19 21:39:39 UTC
(In reply to comment #24)
> And... I thought includes/templates/ was completely deprecated. I thought the
> only part of the UI that used it was Special:UserLogin and
> Special:UserLogin?type=signup and they only did so for historical reasons. I
> could swear there was a bug about killing off these remaining templates (and
> just leaving NoLocalSettings.php, I guess...). I can't find the bug off-hand,
> but adding templates like this seems like the wrong approach overall.

This would be bug 10317.
Comment 26 Matthew Flaschen 2013-03-19 21:47:07 UTC
(In reply to comment #24)
> I'm lost.
> 
> Why was this being implemented with a URL query string and such?

We definitely intend to make it a normal part of core (no query string, it's just there).  However, the query string is meant as a temporary measure.  Besides allowing people to test (this is necessary since the extension version has only ever run on enwiki in production), it lets people do any necessary cleanup to MW messages.

I agree this approach is unusual for MW core.  However, it's more common elsewhere (it's a form of gating).

Again, it is not intended to last unduly long.  The core commit (now reverted, but after addressing concerns will be committed again) suggesting removing the old version completely from core by 1.22.  I don't think that milestone is set in stone.

> And... I thought includes/templates/ was completely deprecated. I thought the
> only part of the UI that used it was Special:UserLogin and
> Special:UserLogin?type=signup and they only did so for historical reasons. I
> could swear there was a bug about killing off these remaining templates (and
> just leaving NoLocalSettings.php, I guess...). I can't find the bug off-hand,
> but adding templates like this seems like the wrong approach overall.

There was some discussion of using a different approach (possibly HTMLForm), but IIRC, it was decided to be out of scope for the initial commit.  That doesn't mean it can't be done later.

> Make Agora a MediaWiki skin and/or improve the core account creation
> interface.

The idea is that Agora will be mediawiki.ui, a separate module.  However, this module does have skin-specific behavior.  So (again in the core commit that was reverted), there is one CSS file for non-Vector (default) and another for Vector.  More could easily be added for other skins.
Comment 27 MZMcBride 2013-03-19 22:23:50 UTC
(In reply to comment #26)
> There was some discussion of using a different approach (possibly HTMLForm),
> but IIRC, it was decided to be out of scope for the initial commit.  That
> doesn't mean it can't be done later.

Right. But rather than staying away from the mess or cleaning it up, you seem to be _adding_ to it with additional templates. Broadly, as I understand it, the idea here was that we were going to clean up the account creation UI and internals in MediaWiki core.

Looking at <https://gerrit.wikimedia.org/r/30637>, I think I'd much rather see time and energy focused on <https://gerrit.wikimedia.org/r/27022>.
Comment 28 Steven Walling 2013-03-19 22:34:29 UTC
(In reply to comment #27)
> (In reply to comment #26)
> > There was some discussion of using a different approach (possibly HTMLForm),
> > but IIRC, it was decided to be out of scope for the initial commit.  That
> > doesn't mean it can't be done later.
> 
> Right. But rather than staying away from the mess or cleaning it up, you seem
> to be _adding_ to it with additional templates. Broadly, as I understand it,
> the idea here was that we were going to clean up the account creation UI and
> internals in MediaWiki core.
> 
> Looking at <https://gerrit.wikimedia.org/r/30637>, I think I'd much rather
> see
> time and energy focused on <https://gerrit.wikimedia.org/r/27022>.

The idea here is not to focus on cleaning MediaWiki internals. I don't think we should permanently add a big mess, but the idea here is to implement interface improvements for the end user, based on our previous testing. 

I can fully understand how the temporary URL parameter implementation feels very awkward, but considering this gives us the ability to gather feedback about design, functionality, internalization, etc. from end users on the wikis while not breaking their current interface, the benefits outweigh having to do a bit of clean up when we want to turn https://gerrit.wikimedia.org/r/30637 on by default.
Comment 29 Steven Walling 2013-03-27 21:06:34 UTC
Just a quick update: there is a new patch in Gerrit (https://gerrit.wikimedia.org/r/55847) which separates out the login changes for review from the account creation changes, which had more issues anyway. However, there's no rush to review that, since we're exploring building on top of Tyler's patch to convert to HTMLForm (https://gerrit.wikimedia.org/r/27022). Notes are at https://www.mediawiki.org/wiki/Agora/Engineering#Changing_HTMLForm
Comment 30 Ori Livneh 2013-04-15 17:02:26 UTC
(In reply to comment #29)
> Just a quick update: there is a new patch in Gerrit
> (https://gerrit.wikimedia.org/r/55847) which separates out the login changes
> for review from the account creation changes, which had more issues anyway.

https://gerrit.wikimedia.org/r/55847 is merged; https://gerrit.wikimedia.org/r/45878 is next.
Comment 31 Ori Livneh 2013-04-15 17:11:18 UTC
(In reply to comment #30)
> https://gerrit.wikimedia.org/r/45878 is next.

That should have been https://gerrit.wikimedia.org/r/#/c/57823/ instead. (Thanks, Krenair, for pointing it out to me.)
Comment 32 Steven Walling 2013-04-24 07:40:01 UTC
https://gerrit.wikimedia.org/r/#/c/57823/ is merged and will soon be ready for testing in production, as soon as we backport it to the current MediaWiki release.
Comment 33 Gerrit Notification Bot 2013-04-24 22:17:38 UTC
Related URL: https://gerrit.wikimedia.org/r/60765 (Gerrit Change I9b03d519af43de147bff0ac509a1154f67cd3a0a)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links