Last modified: 2014-09-02 00:14:06 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 29908 - Classic toolbar should not be enabled on .js and .css pages
Classic toolbar should not be enabled on .js and .css pages
Status: NEW
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 69447
Blocks: edit-toolbar
  Show dependency treegraph
 
Reported: 2011-07-15 16:54 UTC by Helder
Modified: 2014-09-02 00:14 UTC (History)
5 users (show)

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


Attachments

Description Helder 2011-07-15 16:54:53 UTC
I noticed that, WikiEditor is displayed on .js and .css pages (Bug 24713), but the old toolbar is not being displayed at all (i.e., when "Enable enhanced editing toolbar." is not checked - as is recommended on Wikisource projects because of bug 28574).

I think the behavior should be consistent among both types of toolbars:
1) Display the selected edit toolbar whenever the user is editing a page (be it a js page or not); OR
2) Do not display any of the toolbars when editing .js/.css pages

I would prefer option (1).
Comment 1 MZMcBride 2014-01-30 17:03:49 UTC
Eh? Is there a bug about killing the old toolbar. We really should.
Comment 2 Helder 2014-01-30 18:04:38 UTC
Bug 28856 is about moving it into an extension, but I think it will not be killed...
Comment 3 Gerrit Notification Bot 2014-06-22 14:09:05 UTC
Change 141293 had a related patch set uploaded by TheDJ:
Toolbar: Only show on WikiText pages

https://gerrit.wikimedia.org/r/141293
Comment 4 Derk-Jan Hartman 2014-06-22 14:10:35 UTC
The above patch makes the (old) toolbar presence consistent to only show on wikitext content model pages.
Comment 5 Gerrit Notification Bot 2014-07-29 16:52:55 UTC
Change 141293 merged by Mwalker:
Toolbar: Only show on WikiText pages

https://gerrit.wikimedia.org/r/141293
Comment 6 Bartosz Dziewoński 2014-08-15 21:52:59 UTC
Resolved? Not resolved?
Comment 7 George Orwell III 2014-08-17 08:31:32 UTC
(In reply to Bartosz Dziewoński from comment #6)
> Resolved? Not resolved?

Don't think so. See Bug 69447 for starters.
Comment 8 Gerrit Notification Bot 2014-09-01 12:52:14 UTC
Change 156009 had a related patch set uploaded by Helder.wiki:
Revert "Toolbar: Only show on WikiText pages"

https://gerrit.wikimedia.org/r/156009
Comment 9 Gerrit Notification Bot 2014-09-01 14:07:12 UTC
Change 156009 merged by jenkins-bot:
Revert "Toolbar: Only show on WikiText pages"

https://gerrit.wikimedia.org/r/156009
Comment 10 Helder 2014-09-01 14:24:15 UTC
Apparently the intention is to not show the toolbar in these cases (i.e. option (2) of comment 0).
Comment 11 Bartosz Dziewoński 2014-09-01 22:17:16 UTC
The patch has been reverted, back to drawing board.

We need a way to let extensions decide whether the toolbar should be displayed on pages they manage. It seems there are two competing solutions pending:

(Quoting Helder from bug 69447 comment 21)
> 1) Create a function shouldShowToolbar which returns true if the content
> model is wikitext (extensions would subclass EditPage I think):
> https://gerrit.wikimedia.org/r/#/c/157054/1/includes/EditPage.php,unified
> 
> 2) Create a hook to allow extensions to redefined the value of the variable
> $showToolbar:
> https://gerrit.wikimedia.org/r/#/c/120357/6/includes/EditPage.php,unified

I can help review and merge, but don't ask me to decide which makes more sense :)
Comment 12 George Orwell III 2014-09-01 22:53:44 UTC
(In reply to Helder from comment #10)
> Apparently the intention is to not show the toolbar in these cases (i.e.
> option (2) of comment 0).

I'm not certain we can soundly reach any conclusions here until Bug 30795 is addressed and/or resolved first. The "confusion" over the now apparent, poorly labeled User: preference ' Show editing toolbar ' leads to different assumptions and or conclusions when considering the issue at hand.

Some believe deselecting that option should equate to disabling the generation of any toolbar at all - be it 'classic', 'enhanced' or whatever the future may bring. Others believe (correctly) the option only controls the generation of the 'classic' toolbar and is independent or overridden by the User preference that immediately follows it, ' Enable enhanced editing toolbar' (also known as the WikiEditor extension-generated toolbar). Still others are swayed by the internal coding terminology in use, ' usebetatoolbar ', as the rationale to champion the 'classic' toolbar over the other(s) while the opposite know not to place so much weight on the term 'beta' at all and, rightly or wrongly, keep an eye towards VisualEditor becoming the "standard" one day. Sharper differences can be drawn from those basics as well. Even the usurpation of Bug 24713 by Bug 24041 (duplicate) has implications towards "defining" this bug.

So while I personally prefer something along the lines of what I THINK option (1) of comment 0 means, I can't be 100% sure about it until Bug 30795 is addressed. And I don't think any of the semi-related bugs that are a variation on the theme of this one should be acted upon until that happens either.
Comment 13 George Orwell III 2014-09-02 00:14:06 UTC
(In reply to Bartosz Dziewoński from comment #11)
> The patch has been reverted, back to drawing board.
> 
> We need a way to let extensions decide whether the toolbar should be
> displayed on pages they manage. . . .

Why can't we instead make a User preference option (disabled by default) under the 'Appearance' tab, 'Skin' section that toggles the generation of a toolbar in the those .js/.css situations regardless of having the 'sysop' bit (for MediaWiki: namespace .js/.css) or just being a plain-old registered User (for User: namespace .js/.css)?

This way, the option for which buttons can appear in what namespace under whatever toolbar [or not] is remains open for the "experienced" User(s) to manipulate as needed while still being mindful of the "newbies" and the trouble they can get into by fudging-up their .css or .js files accidently. At the same time, the combination of possible editing preferences in place on the 'Editing' tab, 'Editor' section (e.g. 'Classic' [this Bug] vs. WikiEditor [Bug 24041]) play no role either way in resolving the specific issue at hand to boot.

I've never believed in "push" solutions that minimizes User choice; it frequently minimizes User responsibility in the process as well. Take the toolbar away for X reason(s) and you're the 'bad guy' for infringing upon a contributor's "perceived rights". Let the contributor hang themselves by enabling something they didn't know how to use in the first place and there is no 'bad-guy' to blame but themselves.

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


Navigation
Links