Page MenuHomePhabricator

VisualEditor: Edit tab replaced with "Create source" for Education Program pages
Closed, ResolvedPublic

Description

For those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled "Create source". (VE is not enabled in the Education Program: namespace, so it should remain simply "Edit".)

Example institution page:
http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma

Example course page:
http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma/History_of_Science_from_Antiquity_to_Newton_(Fall_2013)


Version: unspecified
Severity: normal

Details

Reference
bz53477

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:58 AM
bzimport set Reference to bz53477.

@James: Any chance of getting this fixed soon? Now is when many instructors who are new to Wikipedia will be trying to set up their course pages, and the mislabeled tab is likely to confuse.

  • Bug 56844 has been marked as a duplicate of this bug. ***

Hi James, just noting for the record that this is still quite problematic, and we very much appreciate any efforts to fix it. :)

Slinging to Alex – not sure what the fix here would be (it feels like overriding the semantics of a tab is something that should involve a class change, really) – thoughts?

I think VE shouldn't be modifying tabs on pages which aren't articles (check wgIsArticle is true before doing anything).

Change 125233 had a related patch set uploaded by Alex Monk:
Only make tab changes on articles

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

From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.

Not one of them is being used by EP right now.

  • It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page).
  • Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id.
  • It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because:
    1. They aren't compatible (the query string parameters Action pages take aren't supported, other than title=).
    2. It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example "View history" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected.
    3. Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.

There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them.

I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).

(In reply to Krinkle from comment #7)

I'd say EP should either let us know how to generically detect it without
being EP specific, or it should implement support to at least do one thing
right. Possibly we could do the latter ourselves (maybe Alex is interested
in patching EP).

I don't really think this bug is important enough to VE to justify making big changes to how another extension works...

andrew.green.df wrote:

I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes.

BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it.

The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)

(In reply to Andrew Green from comment #9)

I can look into making the EP extension warn VE through some generic
mechanism.

Ideally EP would warn VE through the existing generic mechanisms that Krinkle suggested; this would avoid VE having to have EP-specific code in it entirely. :-)

BTW, I wouldn't recommend that anyone try to make major changes to the EP
extension, as the plan is just to rewrite it.

Understood.

Alex's patch also looks like a fine temporary solution. :)

Alex's patch is necessarily a horrible hack, but yeah…

Change 125233 merged by jenkins-bot:
Don't change tabs on Education Program pages

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

andrew.green.df wrote:

Added a comment on the Gerrit change. tl;dr: Is $wgContentNamespaces getting checked? I don't see how EP_NS could be there, and checking it in js seems to fix the issue. Thanks!

andrew.green.df wrote:

P.S. Go to a production wiki and try this in a js console:

mw.config.get('wgContentNamespaces')

The results coincide:

https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L9292-9349

I lost the scent of $wgVisualEditorNamespaces following a brief pursuit, though...