This page is an archive. Do not edit the contents of this page. Please direct any additional comments to the current main page.

Is there a way to make the visual editor save page button save directly, without opening the pop-up window with the edit summary and such, or have another button that does it or an option to check, through personal js or otherwise ? This would be for editing drafts or personal pages where no edit summary is necessary.

And is there a way to keep the visual editor menu at the top even after saving, so that when we're far down on a page we don't have to scroll back up (or use the cumbersome shortcut keys) to visual edit again ? Cenarium (talk) 14:26, 30 November 2014 (UTC)

Also, can we through personal js or otherwise change "Edit source" to "Edit" and "Edit ^beta" to "Visual edit" ? Cenarium (talk) 15:19, 30 November 2014 (UTC)

@Cenarium: Regarding your second question, are there not "Edit source" and "Edit ^beta" links immediately to the right of every section heading? These are intended to avoid the problem you describe - having to go to the top of the page to start an editing session. (And since VE doesn't do section-only editing, clicking on "Edit ^beta", anywhere on a page, opens the entire page for editing with VE.) -- John Broughton (♫♫) 04:41, 1 December 2014 (UTC)

@John Broughton: Yes, but there are pages with no sections (or large sections), which isn't often the case for articles but more so for non-article pages (the need was most obvious when I was editing a page like that). There is also that one still has to click on this section editing button, which could be avoided, especially considering the time it takes to load visual editor. So a way to save the changes without leaving visual editor would be most welcome. Cenarium (talk) 06:05, 1 December 2014 (UTC)

Cenarium, I think that you want the keyboard shortcuts, which work anywhere on the page.

You can change almost any label through CSS. Last I checked, there were no basic help pages to help editors figure out how to do this for themselves, but an inquiry at WP:VPT is usually successful. This link will show you the names of the objects that you want to change: https://en.wikipedia.org/w/index.php?title=Candy&uselang=qqx

There is no way to skip the invitation to provide an edit summary, and I'm certain that this is a WONTFIX issue with the product manager. Whatamidoing (WMF) (talk) 10:35, 3 December 2014 (UTC)

@Whatamidoing (WMF): Shortcuts won't do. I want to remain in visual editor mode after the save. I make edits, I save my edits without leaving visual editor, I edit again, and so on. It would make editing easier and faster, having to use shortcuts is too much of a hassle and it takes too long for visual editor to load. So I think it's a feature that would be very helpful and appreciated, particularly by experienced users. I would suggest a checkbox "stay in visual editor mode after saving". (I would even suggest to have a "visual editor always on" option in preferences, but only further down the line, when performance will have improved.)

Thanks, I know how to hide in css but not how to change a label, so I'll ask at VPT (and I'll update WP:CSS#Tips_and_tricks). I've tried to hide the edit summary help, minor edit and watch checkboxes and the copyright warning of the window though, and couldn't using css, despite them being hidden in source editing. Is it not possible yet ?

I was not suggesting skipping the window as a feature request, but as something that 'power' users could do using personal js. I've thought of something better though :

I would strongly suggest to offer an option to have the edit summary window and minor edit checkbox (everything else is superfluous, or should be allowed to be hidden) together with the edit window, as in source editing. I see two possibilities, both could be offered and the user would choose according to their preference (mostly based on abundance of vertical space versus horizontal space on their respective platform). Either right below the visual editor menu toolbar, or in another box on the left side of the window where the navigation bar takes lots of unused space. Once again, it's something that could be very appreciated by experienced users, contributing to a wider acceptance of visual editor. Cenarium (talk) 14:41, 3 December 2014 (UTC)

Just a follow up on relabeling, I don't think this can be done in css, but I've done so in js, using the following : $( 'a', '#ca-edit' ).text( 'Edit' ); $( 'a', '#ca-ve-edit' ).text( 'Visual edit' ) ;. For sections, the visual edit link was harder to replace and I had to use $( 'a', '.mw-editsection' ).text( 'Edit section' ); $( '.mw-editsection-visualeditor' ).html( 'Visual edit' ); . Cenarium (talk) 21:51, 3 December 2014 (UTC)

Okay, I've been able to hide the edit summary help, minor edit and watch checkboxes and the copyright warning. They had different ids than those for source editing, I used this in css : .ve-ui-mwSaveDialog-summaryLabel, .ve-ui-mwSaveDialog-license, .ve-ui-mwSaveDialog-options { display: none } . But for everything else (saving without leaving VE and summary window alongside the edit window), I think feature requests would be required. Cenarium (talk) 22:38, 3 December 2014 (UTC)

Maybe they're not needed :) It's no secret that at some point VE will allow editors to save some kind of drafts - which would probably work a lot like what you describe. As for the second thing, there's definitely a task in Phab already asking for it. (Links will be provided at some point. Bye for now!) --Elitre (WMF) (talk) 14:42, 4 December 2014 (UTC)

@Elitre (WMF): I've found the bug for simultaneous edit summary and edit window, T52961.

With regard to saving without leaving visual editor, it's very different from a draft system. When working on an article, editors tend to make several edits in succession rather than a big one for several reasons, the main of those being edit conflicts. This would matter even more in visual editor since resolving conflicts would presumably require wikitext editing, which would defeat the purpose of said visual editor. So there should be a way to save without leaving, the visual editor window should update with the user's edit (and non-conflicting edits by other users).

I've tried using custom js to reload the visual editor immediately after leaving it, as a script for wikitext editor does, but couldn't get js to work with visual editor, see section below. Anyway, an in-built way would be much more efficient, since it would reload only the updated elements. As a side note, you should probably update Template:Editnotices/Page/Wikipedia:VisualEditor/Feedback following the move to phabricator. Cenarium (talk) 22:05, 6 December 2014 (UTC)

If "save and stay" is just as slow as "save, exit, and re-open", then will you still want it? Whatamidoing (WMF) (talk) 20:19, 8 December 2014 (UTC)

My point was merely that once the backend code is in place, it can be adapted to what you ask, but yes, it can be added to Phabricator if you want. I think I saw you creating tasks there already? --Elitre (WMF) (talk) 20:58, 8 December 2014 (UTC)

@Whatamidoing It wouldn't be as good but it would at least avoid having to re-click. But my guess is that some elements wouldn't have to be reloaded so it could be made faster. It's already faster when one edits a page a second time.

@Elitre You mean we should wait for a more stable release before delving into user scripts, same for media viewer ? I'll probably file a bug for saving without leaving VE. Cenarium (talk) 22:02, 8 December 2014 (UTC)

No, and filing a task sounds great. Let us know if you need help with that. Best, --Elitre (WMF) (talk) 17:25, 9 December 2014 (UTC)

I've tried using personal js to modify the behavior of the visual editor, but I couldn't make it work. Either it does nothing, or it loads for ever. On the other hand, css works fine. First, how can we check that we're in visual editor mode ? It's been discussed at bugzilla, mainly that visual editor uses "veaction=edit" instead of "action=vedit" which would have allowed wgAction to work. Is there a workaround ? Doing this by testing if a visual editor ui element exists does nothing, and not testing results in an infinite loop. I couldn't find any visual editor related personal scripts, is it not possible at all ? Obviously it would be more than for personal use, this could be very helpful to customize visual editor for the specific needs of a particular wiki. Cenarium (talk) 21:55, 6 December 2014 (UTC)

I've just updated the page Wikipedia:VisualEditor/Customization, which includes at least one script that you may not be familiar with. -- John Broughton (♫♫) 04:01, 8 December 2014 (UTC)

I've expanded the page and linked it in the FAQ. The script relabeling the links runs when viewing a page though, not when using the visual editor. Cenarium (talk) 05:12, 8 December 2014 (UTC)

TheDJ added a link to mw:VisualEditor gadgets which has details on using javascipt with visual editor. I'll take a look. It looks similarly complicated to work with js on mw:Extension:MultimediaViewer. Cenarium (talk) 22:08, 8 December 2014 (UTC)

I'm pretty sure the editors who got the grant for that project would be still glad to guide you a bit. Eran is always around, and such a helpful guy. --Elitre (WMF) (talk) 17:27, 9 December 2014 (UTC)

there is no button to cancel the beta edit as far as I can tell PM ME URANUS (talk) 02:38, 12 December 2014 (UTC)

When hovering over the infobox and other locations which have their own sub-editor, you can not access listed links to test whether they are working correctly or not. Quivico (talk) 04:53, 12 December 2014 (UTC)

This is a known problem. In a few months, it should be possible to edit templates as rich text, in which case you should be able to edit the infobox and then click on the link (exactly as if you were clicking on a link in the regular text of an article). Some links may still be inaccessible, e.g., links that are constructed by the template on the basis of a code, but at least most links should be clickable then. Whatamidoing (WMF) (talk) 20:07, 18 December 2014 (UTC)

Every time I delete a word or change something, it doesn't delete it, it move it to a different spot in the paragraph. Many times it will move the entire paragraph to the next section, but when I click the 'back' arrow to fix it, it doesn't move it back. Srbuckley (talk) 18:22, 14 December 2014 (UTC)

Srbuckley, thanks for your comment. What I need to know about this is:

1. Is it still happening? This week's fixes addressed a similar problem, and may have fixed yours.
2. If it's still happening, then what is your web browser (including version number) and operating system? Whatamidoing (WMF) (talk) 20:09, 18 December 2014 (UTC)

I just read that typing [[ in VE now starts the link dialog, so wanted to test it. Random article (Hotel Elfie), start typing after the existin text, type [[, it simply disappears. I keep on typing and then the link editor opens, but if I'm a bit fast, it only opens after the second or third character, and the first one(s) are plain text. Anyway, I type my link, choose the target, click done, and continue typing. Oops, I am still inside the link, typing the rest of the sentence in blue? Oh wait, I opened the dialog with [[, I probably have to close it now with ]], makes sense! No, it doesn't, now I have a blue ]] :-(

It turns out that whatever I type after I have used "done" on the link selector is not actually included in the link, it is only shown like this while typing. I only found this out by using the "review your changes" function. Not really "Visual" Editor, but anyway... Fram (talk) 14:52, 16 December 2014 (UTC)

And some times it autocorrects the display later, and sometimes it doesn't. Also, if you're a fast typist, you can get type [[dog [Return key] before the link inspector realizes what's going on, and the result will be the unlinked, plain-text word dog (in Firefox; I haven't been able to reproduce this in Safari).

The link-extending problem is not related to the keyboard sequence. Whatamidoing (WMF) (talk) 20:20, 18 December 2014 (UTC)

At Christopher Fowler#Novels and collections, I was able to edit a cell in the first column, and fill in a blank cell in the third column, using VE. But I couldn't figure out how to edit the blank cell in the fourth column that's near the top of the table. Double-clicking definitely doesn't work (FF, most recent version, on a Mac). Suggestions? -- John Broughton (♫♫) 21:24, 14 December 2014 (UTC)

The table structure has no defined fourth cell in this row (a "||" divider is missing). Depending on how VE interprets the syntax that could be a problem, when no editable cell element is prepared. Just a guess though. GermanJoe (talk) 05:51, 15 December 2014 (UTC)

@GermanJoe: - Thanks for spotting that problem. After I fixed it, I was able to use VE to fill the (new) cell.

The larger issue, of course, is whether VE should have identified the discrepancy (one row in the table had three columns, the rest had four). I'm not sure that I'd suggest a warning here, since that implies there would be a relatively easy way for any (novice) editor to fix it.

What does puzzle me is this: Why did VE show the fourth cell in that row as existing - that is, why was there a line on the right (east) side of the space where the fourth cell would have been if it in fact existed? To me, that implies that VE isn't correctly interpreting existing code when it builds (visually) the table. Of course, the standard parser isn't correctly interpreting (displaying) that code either.

So, in the ideal world, VE would not show the fourth cell in the row as existing; it wouldn't issue a warning; and it would make it easy for a user to add that fourth cell. -- John Broughton (♫♫) 04:28, 16 December 2014 (UTC)

They recently removed a lot of stuff that "fixed" bad table formatting, mostly because some of the fixes weren't any better than the problems, but also because a couple of editors complained about unexplained changes to the wikitext. (If you're removing invalid wikitext code, some people want to see an edit summary that directly says you're fixing someone else's screw-up, so that they know that you meant to do this. Also, you could end up with a hundred-line diff even if you're only making a single-character change, which can be very irritating.)

I don't know how you would let people add individual cells, without letting them add individual cells when that was a really bad idea. If Parsoid can figure out that a cell needs to be added, it would make more sense for it to add the (blank) cell. If it can't figure it out reliably, then it also can't let people manually add cells if and only if that cell ought to be added.

A "real" solution would be correcting tens (hundreds?) of thousands of pages so that all tables have valid wikitext markup. Another option would be to 'alienate' the content, so that you can't edit anything in the table, and you see a message that says something like, "This table was created with invalid wikitext markup and cannot be edited until repaired in the wikitext editor". Whatamidoing (WMF) (talk) 20:17, 18 December 2014 (UTC)

Not a solution per se, but a possible improvement if auto-fixing is deemed too risky: Initializing the table background with a slightly different color before creating the cells would clarify the situation a bit for the user. Space inside the table, that is not a valid cell after filling up all available cells, would be shown in the background color instead of plain white. One problem, John mentioned, was that this erroneous space looks exactly like a cell, when only 1 cell is missing. GermanJoe (talk) 09:08, 21 December 2014 (UTC)

The dislay problem appears to be Firefox-only. In Safari, there is no end-of-cell line at the east edge of the table for that row. I've added the "make it possible to fix this!" report separately. Whatamidoing (WMF) (talk) 18:51, 29 December 2014 (UTC)

In this edit, I had to switch to Wikitext to actually remove the header. VE only would remove the text, leaving an empty header, and if I tried to delete further, it wanted to delete the images above the header (and still not remove the header). I know this was a problem earlier, but it seemed to have been fixed. Windows 7, Firefox 34.0.5:Jay8g [V•T•E] 17:58, 20 December 2014 (UTC)

If I am not mistaken, I think you could never remove a header by deleting the text or using backspace etc. To remove it, you have to put your cursor in the header's line and then choose "paragraph" from the drop down menu. TeamGale 18:04, 20 December 2014 (UTC)

Actually, it turns out that this is only an issue is there is something other than text immediately above the header:Jay8g [V•T•E] 00:42, 22 December 2014 (UTC)

It's possible; it's just not easy to see if it worked. You have to remove the entire paragraph, including the line break at the end, not just the words. This is the same model that you use in a word processing document: to get rid of a paragraph including the formatting, you have to select everything ¶, not just the words while leaving the ¶ (and all the paragraph-level formatting associated with it) present. Whatamidoing (WMF) (talk) 18:51, 29 December 2014 (UTC)

Using HTML to add rows of tables is a bit cumbersome, so it would be nice if VE had a way of doing this. (Maybe it does, but if so, it is well hidden and not listed under "tables" in the help section.) Kdammers (talk) 07:50, 21 December 2014 (UTC)

It can be done. Click on any cell and little arrows will appear at the left and top edges for that row and column. Click on the arrow and you get the option to insert a row or column. Mike Christie (talk - contribs - library) 13:57, 21 December 2014 (UTC)

The "Tables" section of the User guide is, I'm sure (without looking), out of date. When things settle down with table editing (I believe that further changes are imminent), then that would be a good time for someone to update this part of the user guide. -- John Broughton (♫♫) 19:33, 25 December 2014 (UTC)

The appearance (of just about everything) should change here on 7 January. There are quite a few more table-related improvements on the way during January. Whatamidoing (WMF) (talk) 18:56, 29 December 2014 (UTC)

I just found a couple of nice features I wanted to pass along thanks for. I tried cutting and pasting an image from one place in an article to another, and that worked perfectly. Then I tried cutting and pasting a ((cite book)) template from one article to another article, inside a VE session in both tabs; that worked perfectly too. That last is a great time-saver for me as I re-use refs from article to article all the time.

I did notice, however, that the "Reuse" citation option was greyed out within the cite menu when I was editing caption text inside an image. (Windows 7, Chrome.) Is that intentional? I had to add it via wikitext. Mike Christie (talk - contribs - library) 19:21, 20 December 2014 (UTC)

The answer is "maybe": It may be disabled due to a problem with crashing if you try to paste into a caption that contains a re-used ref. Fundamentally, the problem is probably T49344, but I've filed it as T85465 so that the specific issue won't be forgotten. Whatamidoing (WMF) (talk) 19:10, 29 December 2014 (UTC)

Geneocide (talk) 00:41, 28 December 2014 (UTC)

This is a known problem. Actually, it's two known problems:

• Speaking as a volunteer, you aren't supposed to be using tht template in the mainspace at all (see the template's documentation page and MOS:Blockquote).
• Speaking as a staffer, all citations within templates are invisible outside of said template, which throws off the numbering as well as making it impossible to re-use the refs.

In the long-term, T49344 will solve the second problem, but the first problem is best solved by removing the template and using proper blockquote formatting. In VisualEditor, that means typing the quotation out like a regular paragraph, and then choosing "Blockquote" from the "Paragraph" styling menu. Whatamidoing (WMF) (talk) 19:23, 29 December 2014 (UTC)

Okay. Thanks. Geneocide (talk) 20:19, 29 December 2014 (UTC)