Page MenuHomePhabricator

Classic edit toolbar should be more accessible for change and modification
Closed, DeclinedPublic

Description

Author: atluxity

Description:
As it is now you got the choice between nasty JavaScript-hacks and editing EditPage.php for changing the toolbar-buttons. It would be better if they were accessible through a WM specialpage.


Version: unspecified
Severity: enhancement
See Also:

Details

Reference
bz14530

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:09 PM
bzimport set Reference to bz14530.
bzimport added a subscriber: Unknown Object (MLST).

Eugene.Zelenko wrote:

Probably you mean same thing as bug 11732.

atluxity wrote:

That does not appear to be so. bug 11732 talks about different toolbar-buttons for different languages, I just want the buttons more accessible for changes and modifications in general.

post wrote:

I.e. if you want to change the standard -- (two hyphens) before the signatures created by the current signature button to say, a — (em dash), you have to hack includes/EditPage.php, you can't change it in a page like [[Mediawiki:EditButtons]].

atluxity wrote:

Yes, thats correct. I belive a Mediawiki-specialpage would be better than having to edit the EditPage.php or doing javascript hacks.

JS Hacks? What are you talking about. Last time I checked the methods for adding buttons to the toolbar were clean JS functions.

There is nothing wrong with that. The buttons use JS to add things into the text box, so there's nothing wrong with using JS to add new buttons. MW makes JS readily available for the site, and also for individual users. Making use of things like [[MediaWiki:EditButtons]] would only help sites, it doesn't help an individual user at all.

post wrote:

The problem is modifying button that at defined in includes/EditPage.php. If i am not very wrong, that is where the singature-button-js is located.

stigmj wrote:

I have made this little hack to do the requested modifications (the "nasty" js-hack):
http://no.wikipedia.org/w/index.php?title=MediaWiki:Monobook.js&diff=next&oldid=3849958

Given that the editbuttons are localized, I think it would be somewhat difficult to do a entirely dynamic configuration of the buttons, but it shouldn't be too difficult to make the image, open, close and key-parameters also a part of the Message-files (ie. localized). This way it would be possible to edit the contents in the MediaWiki-namespace and get rid of awkward js-hacks in the global js-files (as now introduced in nowiki).

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

Krinkle closed this task as Declined.EditedApr 17 2018, 3:56 AM
Krinkle subscribed.

This task appears to ask for a centralised and editor-agnostic way of modifying editor toolbars. I'm going to say, this is not feasible.

We're moving towards a future where editors are modular and pluggable, and can relate to one of multiple content models (wikitext, js, css, json, etc.) and can be in one of several modes (source mode based on plain text, visual based on Parsoid DOM).

I cannot imagine that it is possible to provide a central interface that allows both useful features and can magically map to all possible editors, formats and modes.

Instead, individual features (such as the Cite extension and SyntaxHighlight extension) need to decide individually which editors they want to support, and decide what their buttons should do in those editors. For example, adding a button to the classic monobook toolbar, the WikiEditor toolbar, the VisualEditor source mode, or VisualEditor visual mode, all come with very different abilities and requirements. Only the original feature that adds the buttons can know what it should do.