Eh? Is there a bug about killing the old toolbar. We really should.

Bug 28856 is about moving it into an extension, but I think it will not be killed...

Change 141293 had a related patch set uploaded by TheDJ:
Toolbar: Only show on WikiText pages

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

The above patch makes the (old) toolbar presence consistent to only show on wikitext content model pages.

Change 141293 merged by Mwalker:
Toolbar: Only show on WikiText pages

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

Resolved? Not resolved?

(In reply to Bartosz Dziewoński from comment #6)

Resolved? Not resolved?

Don't think so. See Bug 69447 for starters.

Change 156009 had a related patch set uploaded by Helder.wiki:
Revert "Toolbar: Only show on WikiText pages"

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

Change 156009 merged by jenkins-bot:
Revert "Toolbar: Only show on WikiText pages"

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

Apparently the intention is to not show the toolbar in these cases (i.e. option (2) of comment 0).

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 :)

(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.

(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.

my idea was to have editor extensions register themselves as providers of an editor for arrays of content models, then show those as options to the user prefs, and have the user prefs decided which toolbar to show for which content model.

That is partly based on moving the 'classic' toolbar out of core and into it's own extension. It's quite a bit of work.