P.S. for people that intend on copying this code from core, please note that it's likely GPL licensed, so you should add that license to that gadget/userscript and refer back to a git revision or something that you took it from.

I don't think this is ready for announcing yet - what I asked in T30856#3629674 is still unresolved. If we're going to tell people to just copy/fork the code into a gadget, we haven't really fixed the maintenance problem - we've just pushed it onto other people and given them less resources to do it well by moving it out of MediaWiki.

My proposal would be to split the toolbar into a separate extension, abstracting out toolbar support in core. If we can recruit maintainers (@Platonides maybe? :)) then the extension will continue to be deployed in Wikimedia production, subject to the standard code stewardship process. Otherwise it'll get dropped, but at least we've given people an opportunity to support this properly.

I don't think this is ready for announcing yet

@Legoktm FYI, it was announced yesterday: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Support_ends_for_the_2006_wikitext_editor

Uhh, is someone planning to work on this in that timeline?

Also other places. And last year. And, yes, everyone who has offered to help is ready to do their bit on the schedule that we agreed to two months ago.

@Legoktm, if you wish to file tasks for the two ideas you describe in that comment –

1. Make a pluggable toolbar system.
2. Turn this old toolbar into an extension.

– then you are welcome to do so.

Neither of those tasks need to block this work. My main reasons why these tasks should not block this work are:

• Nobody wants to write that extension. The possibility of turning this into an extension has been discussed in multiple forums for at least the last two years, and nobody has shown any interest in writing the extension. If people were interested in doing that work, I assume that they would have said something by now.
• The extension probably won't be used. I believe that any resulting extension will not be deployed on WMF wikis. It might be welcome on a few third-party wikis; however, this change was announced to third-party users more than a year ago, and I do not recall seeing even a single third-party user request for an extension to replace this toolbar. I'm certain that a user script will get used, but creating an extension might be a waste of your time.

In T30856#4671668, @Legoktm wrote:

Uhh, is someone planning to work on this in that timeline?

Yes.

In T30856#4671705, @Whatamidoing-WMF wrote:

Also other places. And last year. And, yes, everyone who has offered to help is ready to do their bit on the schedule that we agreed to two months ago.

Ack, I missed T30856#4539731 it seems.

@Legoktm, if you wish to file tasks for the two ideas you describe in that comment –

1. Make a pluggable toolbar system.

T28918 ish, but the toolbar part is a smaller aspect.

1. Turn this old toolbar into an extension.

That's this task. It's mentioned in the task description.

Neither of those tasks need to block this work. My main reasons why these tasks should not block this work are:

• Nobody wants to write that extension. The possibility of turning this into an extension has been discussed in multiple forums for at least the last two years, and nobody has shown any interest in writing the extension. If people were interested in doing that work, I assume that they would have said something by now.

I did in T30856#3629674. I think there's significant value in refactoring it into an extension. But my questions were never answered, and still haven't been.

• The extension probably won't be used. I believe that any resulting extension will not be deployed on WMF wikis. It might be welcome on a few third-party wikis; however, this change was announced to third-party users more than a year ago, and I do not recall seeing even a single third-party user request for an extension to replace this toolbar. I'm certain that a user script will get used, but creating an extension might be a waste of your time.

If there are active and willing maintainers, and users who want to use it, why wouldn't it be deployed to Wikimedia wikis? Anyways, my point is that I expect the maintenance required to keep a user script going higher than maintaining it as an extension.

Third party users commented directly in this ticket, see T30856#3335611 for example.

After this toolbar was removed MediaWiki core will come without any editing interface. An idea I do not really fancy. Isn't it time to merge WikiEditor into core now that it was stripped from unmaintainable code? Yeah, it is to easy to install and invoke WikiEdior but this is not my point.

Third party users commented directly in this ticket, see T30856#3335611 for example.

Oh, this was my own rant. Did not read this before I posted.

In T30856#4671769, @Legoktm wrote:

In T30856#4671705, @Whatamidoing-WMF wrote:

1. Turn this old toolbar into an extension.

That's this task. It's mentioned in the task description.

No. "potentially" is a nice-to-have. If you want to do the work, that's fab, but it isn't part of this committed work.

Neither of those tasks need to block this work. My main reasons why these tasks should not block this work are:

• Nobody wants to write that extension. The possibility of turning this into an extension has been discussed in multiple forums for at least the last two years, and nobody has shown any interest in writing the extension. If people were interested in doing that work, I assume that they would have said something by now.

I did in T30856#3629674. I think there's significant value in refactoring it into an extension. But my questions were never answered, and still haven't been.

Sorry, they seemed rhetorical? "Both".

In T30856#4671836, @Kghbln wrote:

After this toolbar was removed MediaWiki core will come without any editing interface. An idea I do not really fancy. Isn't it time to merge WikiEditor into core now that it was stripped from unmaintainable code? Yeah, it is to easy to install and invoke WikiEdior but this is not my point.

It's been shipped in the tarball for six(?) years now.

It's been shipped in the tarball for six(?) years now.

Yeah, it is to easy to install and invoke WikiEdior but this is not my point.

In T30856#4671846, @Kghbln wrote:

It's been shipped in the tarball for six(?) years now.

Yeah, it is to easy to install and invoke WikiEdior but this is not my point.

No, it's mine. It's installed and enabled by default.

Bye! To whatever you like. You do it anyways.

@Whatamidoing-WMF : Hi! I've been willing to test the upcoming deployment to make sure that the gadgets currently used by many on the French Wikipedia still work if the classic edit toolbar is disabled. So, following the information on the page you linked to from my user talk page, I went today to the English Wikipedia on the beta cluster which is currently running 1.33.0-alpha (26665a6). Unfortunately, it looks like the classic edit toolbar has not been disabled there, so I'm unable to test the gadgets from the French Wikipedia as planned.

Has the removal plan changed in the meantime? Am I not testing on the right wiki?

Thanks!

Change 317079 merged by jenkins-bot:
[mediawiki/core@master] Remove old "bulletin board style toolbar" from core

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

@Jdforrester-WMF : Hi! It looks like the toolbar is now gone on the beta cluster, but not on the English Wikipedia (I can't really tell for the French Wikipedia as it has been much hacked there). Does it mean that the timeline on this page has been postponed by one week and that I still have seven days to make sure the gadgets are working?

In T30856#4691074, @Arkanosis wrote:

@Jdforrester-WMF : Hi! It looks like the toolbar is now gone on the beta cluster, but not on the English Wikipedia (I can't really tell for the French Wikipedia as it has been much hacked there). Does it mean that the timeline on this page has been postponed by one week and that I still have seven days to make sure the gadgets are working?

Yes, sorry, you have one week to test.

In T30856#4691858, @Jdforrester-WMF wrote:

In T30856#4691074, @Arkanosis wrote:

@Jdforrester-WMF : Hi! It looks like the toolbar is now gone on the beta cluster, but not on the English Wikipedia (I can't really tell for the French Wikipedia as it has been much hacked there). Does it mean that the timeline on this page has been postponed by one week and that I still have seven days to make sure the gadgets are working?

Yes, sorry, you have one week to test.

That's fine, thank you! :)

Change 469777 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@REL1_32] Remove old "bulletin board style toolbar" from core

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

Hi everyone,

If there's any interest on your local wiki to provide extended support for the the classic edit toolbar, you can port it as a local gadget.

I've documented this approach on mediawiki.org. It has been successfully tested on both the beta cluster and the French Wikipedia.

Best regards

In T30856#4701872, @Arkanosis wrote:

I've documented this approach on mediawiki.org. It has been successfully tested on both the beta cluster and the French Wikipedia.

Thank you! (I appreciate the example ;-))

I note that you suggest to import the whole code to the local wiki.

import fr:MediaWiki:Gadget-mediawiki.toolbar.js on your local wiki;

Don't you think it would be safer to suggest to create a link that would link directly to the ressource on fr?
mw.loader.load("//fr.wikipedia.org/w/index.php?title=MediaWiki:Gadget-mediawiki.toolbar.js
That solution would ease overall maintenance and avoid code depreciation, no?

In T30856#4702196, @Trizek-WMF wrote:

Don't you think it would be safer to suggest to create a link that would link directly to the ressource on fr?
mw.loader.load("//fr.wikipedia.org/w/index.php?title=MediaWiki:Gadget-mediawiki.toolbar.js
That solution would ease overall maintenance and avoid code depreciation, no?

I have mixed feelings about the mw.load approach. Sure, it lowers the burden on the maintainers, but it always costs an additional HTTP request (or at least it did the last time I checked) for all the users of the script.

Feel free to change it if you want. As I won't update other wikis anyway, that might be indeed better :)

I've made the change.

Concerning the HTTP request, I've seen that loading practice commonly used. I don't know if that's a good practice but I've never read the same comment as yours elsewhere. I literally have no idea.

mw.loader.load has two major disadvantages:

1. Code that uses mw.toolbar.addButton must not run before the code is loaded. While this is trivial if you imported and load the code as gadget, it is not so easy if you plainly load the code from elsewhere. Global gadgets (T22153) would solve this.
2. If used outside WMF wikis, loading directly from fr.wikipedia might break on that other wiki, if some code changes were made that are only compatible with master, but not with the version that runs on the external wiki.

I reverted your change. Apart from my above concerns, your code doesn't work at all, since:

1. This tries to load https://fr.wikipedia.org/w/index.php?title=MediaWiki:Gadget-mediawiki.toolbar.js (yes, exactly that HTML page) as JS.
2. You left in the line "add this line in your local MediaWiki:Gadgets-definition: mediawiki.toolbar [ResourceLoader|hidden] | mediawiki.toolbar.js.", which has to be replaced with whatever solution you have for dependency management, as explained in my previous comment.

In T30856#4702333, @Trizek-WMF wrote:

I've made the change.

Thanks!

Concerning the HTTP request, I've seen that loading practice commonly used. I don't know if that's a good practice but I've never read the same comment as yours elsewhere. I literally have no idea.

People didn't talk much about that the last time I checked either. That's because:

• developers care about their Internet access, so they have fast Internet and most of them never use poor connections ''for real'';
• non-developers don't understand why everything is slow — at best they complain, but most of the time, they live with it;
• automated tests don't test what's is not builtin (again, the last time I checked).

Is it not better to place this gadget on Meta!?

In T30856#4702333, @Trizek-WMF wrote:

Concerning the HTTP request, I've seen that loading practice commonly used. I don't know if that's a good practice but I've never read the same comment as yours elsewhere. I literally have no idea.

Unfortunately, it is the recommended practice (per mw:ResourceLoader/Migration guide (users)#Keep gadgets central), at least until we get Gadgets 3.0' global repository (T22153)

@tomasz noticed that the function mw.toolbar.insertTags (and its deprecated global alias insertTags) has also been removed in this change. I think this might have been unintentional? The function doesn't really have anything to do with the toolbar (it inserts text into the editing textarea), it was just unfortunately in the same namespace. Perhaps it could be restored, and then renamed (maybe under mw.util)?

In the meantime, if any important gadgets are failing with errors like "ReferenceError: insertTags is not defined.", they can be fixed with a change like this: https://pl.wikisource.org/w/index.php?title=MediaWiki:Gadget-shortcuts.js&diff=2107359&oldid=293638

@matmarex no that is intentional, see also: T88976: mw.toolbar.insertTags should be independent from mediawiki.toolbar module, T166601: Fix CharInsert to not use mw.toolbar.insertTags and https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-charinsert-core.js&diff=852708515&oldid=852704406

The most common gadget across wikis that hasn't been generally upgraded to use jquery.textSelection directly is charinsert, which looks to be outdated on 34 wikis: arwiki, arwikiquote, aswiki, azbwiki, bhwiki, bnwikisource, bswiki, cawikiquote, cawiktionary, ckbwiki, eswikinews, fowiki, glwiki, glwikibooks, glwikiquote, glwikisource, gomwiki, kuwiki, kuwiktionary, mwlwiki, orwiki, pnbwiki, pswiki, ptwikisource, simplewiki, srwikibooks, srwikiquote, srwikisource, srwiktionary, tawikisource, tewiki, viwikiquote, viwikisource, zh_yuewiki. As Arabic Wikipedia is the biggest of these, I made a quick localised version of the current enwiki version and pinged them on https://ar.wikipedia.org/wiki/%D9%86%D9%82%D8%A7%D8%B4_%D9%85%D9%8A%D8%AF%D9%8A%D8%A7%D9%88%D9%8A%D9%83%D9%8A:Gadgets-definition.

charinsert

also known as edittools on some wikis, e.g. (currently broken on) https://www.mediawiki.org/wiki/MediaWiki:Gadget-Edittools.js

In T30856#4713960, @Jdforrester-WMF wrote:

The most common gadget across wikis that hasn't been generally upgraded to use jquery.textSelection directly is charinsert, which looks to be outdated on 34 wikis: arwiki, arwikiquote, aswiki, azbwiki, bhwiki, bnwikisource......

@Jdforrester-WMF, I have upgraded the the charinsert gadget in bnwikisource as per your instruction in arwiki. It appeared again. But we would like to get it above the edit box as before, not below it. Your help is needed.

In T30856#4719446, @Bodhisattwa wrote:

But we would like to get it above the edit box as before, not below it. Your help is needed.

Right now the controls (held in the editpage-specialchars element) are put into the document just before mw-editTools, which is below the textarea. This is done by the line:

placeholder = $( '<div id="editpage-specialchars"> </div>' ).prependTo( '.mw-editTools' )[0];

If you want to move it to above the text area, you can change this line to suit. The most reliable part of the document to put it next to is wpUnicodeCheck, which is right at the top. Hope this works! However, re-designing the gadget is a bit off-topic for this task. :-)

Change 469777 merged by jenkins-bot:
[mediawiki/core@REL1_32] Remove old "bulletin board style toolbar" from core

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

For those tracking this change:

• https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#haben_Hamster_die_Bearbeitungssymbole_verschluckt?
• https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Bots_and_gadgets/mw.toolbar_zurück
• https://de.wikipedia.org/wiki/Wikipedia_Diskussion:Kurier#Nutzer_des_2006er_Wikitext-Editors_müssen_auf_eine_neuere_Version_umsteigen

No feedback from English Wikipedia yet.

https://fi.wikipedia.org/wiki/J%C3%A4rjestelm%C3%A4viesti:Edittools.js is reported to be broken on the Finnish Wikipedia:

https://fi.wikipedia.org/wiki/Wikipedia:Kahvihuone_(tekniikka)#Viitteit%C3%A4_ei_saa_napsautettua

@Stryn you need to fix fi.wp.org JavaScript that adds those elements below the edit field to make use of jquery.textselection instead of insertTags. An example is linked higher up in this thread.

It appears that the German Wikipedia has a broken gadget that is interfering with CharInsert/EditTools. If you are looking for this:

and not finding it, you don't need the 2006WTE back. Instead, you need to find and fix your broken local gadget.

I had a minute to spare. It seems that the original 'char insert' modification that de.wikipedia.org was running, was:
https://de.wikipedia.org/w/index.php?title=MediaWiki:Onlyifediting.js
This was disabled (because of the errors) in
https://de.wikipedia.org/w/index.php?diff=182493539&oldid=175658964&title=MediaWiki:Common.js
Because of that, there were still no char insert tools.

Since, someone reinstated the 'vanilla' char insert Edittools
https://de.wikipedia.org/w/index.php?diff=182517410&oldid=58236364&title=MediaWiki:Edittools&diffmode=source

Because this doesn't provide all functionality, some people are of course not satisfied. This can be solved by repairing onlyifediting.js:
https://de.wikipedia.org/w/index.php?diff=182544916&oldid=182542209&title=Benutzer%3ATheDJ%2Fonlyifediting.js&type=revision
seems to do the trick. [edit: diff was updated]

I would however advise the community to checkout the english version:
https://en.wikipedia.org/wiki/MediaWiki:Gadget-charinsert-core.js
which helpfully remembers the last selection of the dropdown. I must say that the array style definition of the de.wp version is nicer than what is currently in the English wikipedia version however.

Are statistics on toolbar usage still available for wikis not included in previous batches? Maybe in the form of ‘who doesn’t have any toolbar enabled’? Some people in ruwiki are making quite a big deal out of feature that seemingly wasn’t used that much, but previous analysis here wasn’t made for us.

In T30856#4730003, @stjn wrote:

Are statistics on toolbar usage still available for wikis not included in previous batches? Maybe in the form of ‘who doesn’t have any toolbar enabled’? Some people in ruwiki are making quite a big deal out of feature that seemingly wasn’t used that much, but previous analysis here wasn’t made for us.

Sadly, no. Because we removed the preference, any statistics I pull from the database will be incomplete – any user that has touched their preferences (e.g. enabled a gadget) since the code went live on Thursday and again on Monday will have normalised their settings to drop this option. I can generate some quick numbers if you want, but every user that's noticed, is unhappy, and has done something to fix it for themselves will not be counted, which will be misleading.

In the other direction, counting users who have the 2010 wikitext editor disabled will inflate the numbers quite a lot (from memory, on wikis I looked at, there were lots more users who opted out of both the 2010 and 2006 editors than who opted out of the 2010 one but were using the 2006 one).

Discussion was moved from tech wishlist to https://meta.wikimedia.org/wiki/Wikimedia_Forum#mw.toolbar_zurück in an attempt to stop the disruption of that process.

In T30856#4671836, @Kghbln wrote:

After this toolbar was removed MediaWiki core will come without any editing interface. An idea I do not really fancy. Isn't it time to merge WikiEditor into core now that it was stripped from unmaintainable code? Yeah, it is to easy to install and invoke WikiEdior but this is not my point.

I agree with this comment. Having no edit toolbar without installing an extension is weird.

In T30856#4734338, @Bawolff wrote:

In T30856#4671836, @Kghbln wrote:

After this toolbar was removed MediaWiki core will come without any editing interface. An idea I do not really fancy. Isn't it time to merge WikiEditor into core now that it was stripped from unmaintainable code? Yeah, it is to easy to install and invoke WikiEdior but this is not my point.

I agree with this comment. Having no edit toolbar without installing an extension is weird.

This request is now available at T209217.

@TheDJ

Discussion was moved from tech wishlist to https://meta.wikimedia.org/wiki/Wikimedia_Forum#mw.toolbar_zurück in an attempt to stop the disruption of that process.

It's now re-added to another wishlist: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Editing/Put_mw.toolbar_back, which is now the 6TH wishlist item.

After carefully analyzing this wish, the Community Tech team has decided to decline this wish. There are two primary reasons why. First, the issue has largely been resolved. Second, the wish conflicts with team policy. You can read our rationale and proposed workarounds for people who are still interested in such support in our 2019 wishlist status update report. Thank you!