Forum:New Visual Editor: Problems and Suggestions

This thread covers feedback (suggestions and bug reports) about the new editor.


 * Archive - Forum:New Visual Editor: Problems and Suggestions/archive

Template Display
Only the name of the template is displayed in the visual editor. It can be very clumsy if you use quite many templates in the page. Suggestion: It should display the template code rather than the template name, e.g. display rather than

I use template bc as an example to illustrate the problem.

 Level 0:

It will displays like the following in the visual editor:  Level 0:
 * bc
 * bc
 * bc
 * bc
 * bc

Here is the actual screenshot taken:  Every entry looks the same in the visual editor. It becomes clumsy and inconvenient.

I hope the visual editor displays in the following manner:  Level 0: And I can edit the template code directly, not through the dialog.--MyBrute Resource Center@Ronga 17:39, 23 April 2009 (UTC)
 * If it displayed the template code, it wouldnt be a wysiwyg/visual editor now would it? Thats what the source/raw editing mode it for, to edit the wiki TEXT directly. If you are comfortable with editing wiki formating text directly, you can always just disable the editor from loading at all in your preferences. --Uberfuzzy 18:01, 23 April 2009 (UTC)


 * Well it's still the visual editor since other wiki effects should be rendered (e.g. bold, italic, underline, lists, tables and so on) and I'm happy with it. Make sure you don't confuse between wiki texts and template texts. I see few benefits in showing the name only rather than in full. Showing name only don't make sense in some situations. As shown in the example above, all entries look the same, making it confusing and harder to work.
 * Don't display in this way:
 * Display it in this way:
 * I can work with the wikitext (raw) mode but other visitors can't. There are many on the pages which confuse them when the visual editor is on.  is only a simple template to create a specific kind of links. Visitors do use a lot. The visual editor makes them more difficult to work with templates. --MyBrute Resource Center@Ronga 19:21, 23 April 2009 (UTC)


 * Also noted below: the template flow in the new editor is certainly something I want to look at again. Unfortunately, there are also some restrictions which prevent us from showing templates inline in their final form ... however, on the other end, returning all the wikitext in the WYSIWYG editor is also not ideal. One possible solution could be to indicate that a template can have/has extra parameters - and show that more clearly on the input screen. 11:54, 27 April 2009 (UTC)

Here's the complain recently received from my visitors:

Quote:  yo dawg i tried editing that wiki-article to add 1 brute, but i dunno how to do it with that bc-thingy

"bc" is the name of the template. They are confused about it since the visual editor only shows a lot of "bc". My visitors aren't proficient at wiki-editing. The visual editor is meant to help newbies and encourage them to participate.

To clarify, I'm not asking to show all wikitext in full (i.e. as source code). I'm asking to change ONLY how the template is displayed, not others. There are currently three forms of display:
 * the final output of template (the best but not possible technically)
 * display the template code in full (similar to how Wikipedia full editor works)
 * display the template name only (Wikia's visual editor)

It's still inconvenient even if I can mouseover to view the extra parameters. Mousing over to each entry just to know the difference is inefficient and clumsy. What can be better than this when we can view the difference at a glance?

Wikipedia full editor is superior than ours. I believe we should follow how Wikipedia full editor works in this case. If we display .....  in full in the visual editor, why not for the template? Displaying template name only serves no good purposes. It even confuses my new editors. Displaying template in full may not be ideal, but it's currently the best possible option available.

I'm seriously thinking about removing the template just to overcome the usability problems of the visual editor, so as to accommodate to my visitors.--MyBrute Resource Center@Ronga 17:49, 29 April 2009 (UTC)

Yes, I get the same problem on the Design Platform wiki. The way templates are displayed currently in FCK is not user friendly, netheir advanced users friendly. I get the following problems :
 * User : "what is this yellow box ?"
 * User : "How can i change this content ? It doesn't appears anywhere..." (it's in this yellow box, lol)
 * Advanced user : "It is boring to right click when you need to modify a something insde a box."

It's some time I'm thinking of a redesign of the boxes. I made an architectural proto in 5 min because I have to go (beurk text size...), yet tell me what you think about it.



In an ideal it would also be possible to add in templates : I'm willing to have a reflexion about it.
 * Description for fields (appear when you let the mouse on it).
 * Use a display label in spite of the name of the parameter.
 * Specify if some parameters are rarely used and should be displayed in "more". (all content such as "200px" should be in "more" -wich make me thinking that "more" could be "advanced".)
 * Having a drop down menu for some parameters.
 * In "more" or "advanced", there could be a box to add a parameter (if exists in the template but not already used on page).

Hve a nice day.

--Ttibot 07:23, 4 July 2009 (UTC)

Auto de-wiki is not good
I find that the visual editor will de-wikify most (all?) wiki symbols or HTML symbols. Examples include ==== 4th heading ====, &lt;ref&gt; ( source ) &lt;/ref&gt;, &lt;references/&gt;, to name but a few. The visual editors treat all such inputs as PLAIN TEXTS. Other visual editors like the blogging editors, forum editors work in the opposite ways. They all accept typing some HTML codes (blogging) or BBCodes (forums) in the visual mode. The codes will still be rendered when sent.

Your visual editors couldn't contain all features in the toolbars. Manual insertions of some codes are inevitable. Think about it. You have to keep toggling back and forth just to put a 4th heading, or a source, or a reference list and so on.

Change the behavior of visual editor so it doesn't de-wikify most or all codes by default.

Consider adding an icon for instead, so people can de-wiki the codes with 1 click when they really need it. --MyBrute Resource Center@Ronga 20:39, 23 April 2009 (UTC)
 * I understand what your saying, but your looking at it the wrong way. The idea is to not have people typing ANY code, what so ever, manually into the editor. If you know what your doing with the code, then switch to source mode and type in code. Headers, tables, templates, formatting, should all be done via the toolbar. Anything you actually type should be left as exactly as is. Its called "What you see is what you get" for a reason, if you see a link, you should get a [ and [ and link and ] and ], not a link. --Uberfuzzy 21:40, 23 April 2009 (UTC)
 * Wikia introduces new paradigm into usability: We know how you want to use our features, it's the users who have to learn what to want! -- ◄mendel► 22:52, 23 April 2009 (UTC)
 * LOL! Nice put! Gonna give up. Apparently great but brings more headache than relief. Good examples: Table! Table is really hard to work with in source mode for novices and intermediates. Bad examples: 4th or higher level headings, horizontal line, simple formatting and style unavailable in the toolbar, template display and insertion.............. If the developer can transfer a few good features to the old editor, very happy to stay with the old one.
 * There are currently 3 modes, the visual mode, the wikitext mode (in visual editor), the old editor. The wikitext mode in the visual editor still causes some problems. Wanna work with old editor, except when I have to work with tables. I hope we can save two settings, one for visual table editing, one for the rest. Keep toggling is very tedious. --MyBrute Resource Center@Ronga 07:23, 24 April 2009 (UTC)

My reply is as follows: Quote:  The idea is to not have people typing ANY code, what so ever, manually into the editor. But we are far from it. I have yet to see any visual editor which can let us do all the effects via the toolbars. What are we going to go if the toolbars don't provide what we want? Visual editor is to help people to type fewer codes, but not prevent them from typing any code. People can't type code =/= People don't need type code.

Quote:  If you know what your doing with the code, then switch to source mode and type in code. Well, in fact, most people who have to type a few codes are NOT experienced coders, including me. Many are still novices and visual editors do help significantly and encourage their participation. However the current behavior of the visual editor causes more problems than benefits. Hmmmm.............

The intention of visual editor is to encourage participation. Telling people to switch back to source mode just to type a few codes IS NOT user-friendly, and is going to discourage participation. They don't do it when they feel hard to do.

Quote:  Headers, tables, templates, formatting, should all be done via the toolbar. Your toolbars only have ten something but there are over 100 styles and formatting people want to do. Let's say I want to make a 4th heading, or put a horizontal line, or change the size or color of the text, or put a reference, or put a gallery............... How to do?

We type directly in the past. It takes only 1-2 seconds. Fast and efficient. Tell us how to teach people to insert templates in the new visual editor without being so clumsy, slow or inefficient.

Quote:  if you see a link, you should get a [ and [ and link and ] and ], not a link. At least many visual editors (blogging and forum) don't work in this way. I doubt how many times when people type link, they want link rather than link.--MyBrute Resource Center@Ronga 07:15, 24 April 2009 (UTC)


 * Can you please do not use blockquote when commenting sections of other peoples comments? i keep thinking those are examples due to the indentation they have in respect to your own comments.
 * Now about subject i prefer to use old editor because i already have tools that aid me also with the new editor i have to keep switching back to source because i need to edit something that the new editor cant do or im working with long complex templates and the new editor crashes changing modes--
 * So what should I do if I want to quote and reply (just like what I did in forums)? This seems the best way to do. Years have passed. The forum features of wiki is still the worst I have ever seen. I think the Mediawiki development team should just implement some open-source forum software into wikia.--MyBrute Resource Center@Ronga 14:21, 25 April 2009 (UTC)
 * Well i remind you this is a wiki-page with a forum like interface (see Help:Forums. Thought there are phpBB forums but have to be request and are "experimental". For the open-source there is MediaWiki you can create an Extension and submit it and then ask for the addition to wikia --
 * That is it! A true forum rather than a pseudo one. The so-called wiki forum misses most of the basic forum features. Frankly it's pretty hard to read and reply in long discussions. I'm afraid I'm not skilled enough to create an extension for Mediawiki. --MyBrute Resource Center@Ronga 21:41, 25 April 2009 (UTC)

Okay, a couple of thoughts about the above notes: Thanks for your suggestions, and all your thoughts are appreciated. Please, add more! 11:48, 27 April 2009 (UTC)
 * 1) This is intended as a Word-like editor, not a forum-like or wikitext-like editor. MS Word is what most people are used to. Though much of our audience is geeky, we do not wish to restrict ourselves to this group and scare off newbies.
 * 2) Lack of headings options below H3 - this is fair, but we don't want to clutter up the interface. Generally, once you're below H4, you're getting the to the point where the page should be reorganised or split up. I will make a note of this.
 * 3) References: we plan to support these in future. They're near the top of our list.
 * 4) Formatting: wiki article formatting should be simple. While some people like to design stuff with spans and div styles, you really should avoid it as much as possible, as it's complicated, hard to maintain and use. However, classes and IDs are more reasonable: but if you're advanced enough to use them, you're advanced enough to switch to source mode as and when needed. The editor is not intended to entirely replace the old editor, but to make the large majority of the tasks easier.
 * 5) Template addition: we are not entirely happy with the template usage flow at the moment, and it's also on our list to improve.
 * 6) Wikitext-in-WYSIWYG. This is currently top of our list of features to work on: we totally understand lots of people want to type link or ~ . It's simple and fast. Our intention is to allow you to type them and then convert them via a click.
 * 7) Stability: Cizagna, do you have any specific situations where crashes/breakage happens?
 * I will double check it as it was back in Nov or Dec when i made it crash a couple of times. --

@Kirkburn Here's my reply: After all, the real problem is, in case if you don't see, it makes it more difficult not only to experienced editors, but also to new editors. Simply put, your visual editor fails to satisfy both advanced editors and new editors. Yep! I am meant to say new editors too.
 * 1) OK. I want to stress that I want it to be a Word-like editor too. I'm also putting newbies in mind. We concur in this matter.
 * 2) However we have to realise our visual editor is still far from a proper Word-like editor. It would be great if it finally come out to be a true Word-like editor, but it isn't now. Number 1 difference is I don't have to switch in Word. The interface of Word provides everything (styles and formatting) I want. Tell me, how can I put a H4 heading in the visual editor? Your interface simply don't allow styles and formatting not listed in the toolbars. Word doesn't. We can do all styles and formatting without switching off the Rich Text Mode (Well! It actually has no such needs!).
 * 3) Well, it's initially a response to the above. It's because he says visual editor is meant not to type any code. I simply point out there are too many things we can't do in visual editors. His target hasn't been met. Heading is only one of the common examples.
 * 4) References: Good!
 * 5) Formatting: Well, one point of reminder, Wikia isn't Wikipedia. If it were Wikipedia, it might be true. It's Wikia, a site which host thousands of sites with very different purposes. Different sites can have very different styles. Don't you think there isn't "one size fits all" in the world?
 * 6) "The editor is not intended to entirely replace the old editor, but to make the large majority of the tasks easier." Yep! I agree. But if it's meant we should switch to source code mode just to put in  . That's not okay. Newbies knowing how to put  is nowhere near to wiki experts. ;)
 * 7) Template addition: Here's another example. Creating redirect pages can be a problem, for example. It's really dumb that we can't type the command #REDIRECT somepage directly in the visual editor. Please go and take a look at other visual editor. They always treat them as the code, not the plain texts.
 * 8) Wikitext-in-WYSIWYG: Why not just let us insert wikitext directly? I think it's pretty weird to think when people type wikitext, it's meant to be plain text, not wikitexts. Wikipedia full editor allow it. Tons of other visual editors allow too. It can solve most of the problems addressed above.
 * 9) Stability: I did encounter stability problems, but I'm not sure how it happens. I'm working with a few tables. All wikilinks and nowiki tags are broken when I press sent. I will give you an example when I found the link.

I do think visual editor is the right step to do and is not a bad addition. Thanks for your efforts. I appreciate it even if I left many criticisms. I'm doing it with the best of intentions. Hopefully you won't take it as offense. Keep up your work. See you! --MyBrute Resource Center@Ronga 21:23, 29 April 2009 (UTC)


 * Previously, Wiki users mastered the learning curve towards advanced page design by copy & pasting other people's designs and then fiddling with them. This is pretty seamless if you start off with the source editor anyway (and you may have noticed some features by simplying doing beginners' edits, such as how templates are used), but if it requires a conscious decision to step away from the visual editor and thus abandon everything you have learned so far about wikiediting, it seems to be a huge break. I find that semiadvanced users are able to use simple classes on tables if they have examples (such as class=sortable). -- ◄mendel► 23:07, 5 May 2009 (UTC)

Suggestions
Some of these requests may be pie-in-the-sky, but I figured I'd give it a shot. I'll add more as I think of them.
 * Allow PRE to have a right-click menu to make it do &lt;tt&gt; or &lt;code&gt; instead.
 * Allow S to have a right-click menu to make it do &lt;sup&gt; or &lt;sub&gt; instead.
 * In table menus, add a class entry field to Cell and Table properties. Add a Row properties choice with alignment and class entries.
 * Add a menu to insert HTML entities, like &amp;copy; ( &copy; ), &amp;reg; ( &reg; ), &amp;lt; ( &lt; ), &amp;gt; ( &gt; ), &amp;rarr; ( &rarr; ), &amp;larr; ( &larr; ), etc. Maybe even &amp;#91; ( &#91; ), &amp;#93; ( &#93; ), &amp;#123; ( &#123; ), &amp;#124; ( &#124; ), &amp;#125; ( &#125; ), etc.

Also, are there any complex wikis that have this New Visual Editor? I'd like to see how it renders some of the more complex templates. -- Fandyllic  (talk &middot; contr) 12:54 PM PST 27 Apr 2009


 * None that immediately come to mind, but anything created since about last November should have it. However, complex templates should pose no issues - they aren't rendered inline, and the popup previews should render the same as the final result. Good to test, though.
 * As for the ideas, rather interesting. Thanks! 20:14, 27 April 2009 (UTC)

Tables formatting
One problem with the Rich Text Editor that has moved us to request Wikia staff to disable it at our wiki, Sryth Wiki, is that when a user edits a table that is formatted like this: using the Rich Text Editor, the table gets formatted like this: These changes make nigh-impossible to quickly check for changes in the page's history, so an editor has to manually change the table code to the previous format only to be able to check for changes in the table. Scarbrowtalk 22:45, 27 April 2009 (UTC)


 * This is somewhat unavoidable, unfortunately, due to how FCK works with tables. However, it will only happen once to them, as they get converted to the slightly longer form. 14:26, 28 April 2009 (UTC)


 * That would be quite a problem for a table like this one. Glad we don't have it on fr.guildwars. — TulipVorlax 15:49, 28 April 2009 (UTC)


 * Certainly I recognise the possible issue there. I will bring it up, though I cannot promise anything. However, there is the ability to switch off the new editor on specific pages if it is going to be a major issue (see Help:New editor for more info). 18:05, 28 April 2009 (UTC)


 * A fast way to do is to add dummy HTML comment in a specific page. Actually it's weird that we are disallowed to use visual editor at all once the page contains HTML comments. Consider Wikipedia-like sites. They may occasionally use editors' notes. It will make the visual editor pretty pointless. Wikipedia full editor doesn't have such restrictions. --MyBrute Resource Center@Ronga 19:14, 29 April 2009 (UTC)

Why couldn't I edit the some wikitexts
Let's say we put things like in the page:
 * ..... < /pre>
 * ..... < /ref>

The visual editor can display them in full (unlike the template, only displaying the names) but it doesn't allow us to edit directly. Why not? Wikipedia full editor allows us to edit them directly. Just point to there and type. Hopefully we can do the same here. --MyBrute Resource Center@Ronga 19:11, 29 April 2009 (UTC)

Creating wiki links become more painful in new visual editor
If we want a fast wiki link in the past, we simply highlight the word and click http://images.wikia.com/common/releases_200904.5/skins/common/images/button_link.png. Talking about 1 second time.

Now the visual editor presents us with a new dialog. It's nice but it doesn't take efficiency into account. No making each wikilink becomes slower and painful. Imagine if we want to make like 10+ of links. We have to load 10+ dialogs. Loading --> Dialog pops up --> type and press ok. Talking at least about 5 seconds. 10 seconds vs 50 seconds per 10 wikilinks.

You may leave the dialog option, but please add the simple shortcut too: http://images.wikia.com/common/releases_200904.5/skins/common/images/button_link.png.

It also adds some unnecessary junks. For example if the link name and the text is the same, it is displayed as link rather than link. --MyBrute Resource Center@Ronga 19:11, 29 April 2009 (UTC)


 * Very good point. The link creator button should have a quick link mode that doesn't ask for a label. Personally, I only use the new visual editor to find bugs and make suggestions. It is way too clunky to actually use if you are comfortable typing out wikicode. I'd rather most of it's features just be optional. -- Fandyllic  (talk &middot; contr) 2:44 PM PST 30 Apr 2009

How to reproduce the link switching bugs
Setup:

Create two sections (you can actually use 1 section but read on anyway) Sample text:

Section A

 * gen (Stat at Lv2: HP 71, 2-3-4 // Speciality: Extra Thick Skin, Net // Weapon: None)

Section B

 * punching-bag (Stat at Lv2: HP 77 2-2-4 // Speciality: None // Weapon: Knife)

Steps:

Make sure you turn on rich-text editor! 1) Edit Section A. Cut a statement with external &/or internal links. Save it. 2) Edit Section B (or re-edit Section A). Paste the statement. Save it.

Result:
 * All links are screwed up.

Is it helpful for you to pin which part is causing problems? How long could you fix it? This bug is really critical and annoying which affects us on a daily basis. --MyBrute Resource Center@Ronga 05:04, 30 May 2009 (UTC)


 * Aha, this is a cutting and pasting issue? That's one I managed to reproduce fortunately, will pass this on. Thanks for the extra info! 16:20, 1 June 2009 (UTC)


 * A quick update on this: we are working on various fronts to prevent this issue from occurring. At the moment, part of our solution (which is live) is to prevent copying and pasting in situations where such breakage would occur. The explanation of why is fairly long, but a quick summary would be that if you imagine different parts of the page code are numbered: when you copy sections it is possible these numbers will show up twice on the same page, confusing the editor. 17:41, 10 June 2009 (UTC)

A quick summary of suggestions and notes so far
19:03, 10 June 2009 (UTC)
 * Reintroduce edittools in some fashion.
 * Tweaks to how templates are displayed.
 * Changes to how certain types of wikitext is wrapped in nowiki makers by the new editor
 * Table formatting uses longhand, rather than the sometimes more useful condensed form.
 * Improvements to the display and editing of advanced wikitext.
 * Allow the old way of creating internal link http://images.wikia.com/common/releases_trunk/skins/common/images/button_link.png (no dialog mode)
 * Don't create redundant link format like My Brute
 * Support direct typing the template code like, or other wikitexts that are not available in the toolbox
 * Allow changing the values and code in the template, reference etc. without switching off the visual editor.
 * Allow using visual editor even if the page has HTML comments.

MyBrute Resource Center@Ronga 17:00, 18 June 2009 (UTC)

Preformatted text is being corrupted by extraneous line-feed characters
I was sent for a real spin after using the Visual Editor to create a page that needed to show listings of code excerpts. Traditionally this would have been achieved using either HTML pre or code tags but I decided to let the new editors PRE tool take care of these blocks of pre-formatted text. (There being no CODE tool in that editor - which is fair enough.)

The result while entering the text was perfectly fine i.e. if WYSIWYG then I'd have been happy ... but it isn't WYSIWYG. (Unfortunately this lead me into a false sense of security.) Upon preview the text that was in PRE blocks get's extra line-feeds before and after each line. This massively increases the length of each PRE block to the point where readability is abysmal and article length is frighteningly long.

Making matters worse is the fact that switching to full (source) editor and then back to new editor adds even further anomalies - mostly in the form of extra new-line characters.


 * Review this revision history comparison for an example of the damage new editor does to PRE blocks: comparison

The HTML pre tag is not being used by the PRE block. Instead a single space indent is being used ahead of every line within the block ... including blank lines. Whether this is standard Wiki markup language or not I do not recall but it is definitely causing much grief to an article that would normally be quite straight forward to create and maintain.

Adding insult to injury - now that I am using pre../pre HTML tags to achieve the desired PRE blocks for these code snippets the new editor does not render these pre blocks correctly.

I have since added the __NOWYSIWYG__ special word to that page to default to the source editor. I hope this performance of the new editor can improve - I see it has been around for 2 months or so and nobody has yet commented in this feedback thread on the mishandling of PRE blocks.

najevi 03:22, 11 June 2009 (UTC)


 * That's a good point - I am not sure why the new editor is not using  blocks. While a space at the beginning of a line is appropriate for single lines, it certainly isn't for multiply lines. I will bring it up.  14:02, 11 June 2009 (UTC)

Some clarification after running a controlled test. (before and after is here) The line feeds are added even if I never switch to the WML source editor. These additional new lines are added: You can run a very simple test case in your favorite sandbox to demonstrate this. If you try it and it does not reproduce for you then post here and I'll take some screen shots for you. najevi 14:11, 11 June 2009 (UTC)
 * 1) after the preview button is pressed
 * 2) after the saved button is pressed


 * Thanks ... I've been able reproduce it from your sandbox. Will pass it on to the tech team. 16:01, 11 June 2009 (UTC)


 * FYI I have an example showing that    blocks can be significantly different from using a space indent. 60.241.171.136 08:55, 13 June 2009 (UTC)


 * Thanks for that really clear example - I've passed it on. In your opinion, which is "better" for most cases? I lean towards  here, given how it properly treats code as code.  10:35, 15 June 2009 (UTC)

Critical tags and magic words on "Main_page" are corrupted by the new editor
Using the new editor to add to the Contents section links to half a dozen articles created in the first couple of hours after creating a new wiki yielded alarming damage to some very important magic words and tags used on that page.

This is best illustrated by viewing this history comparison of the vsk.wikia.com main_page.

Very important tags and magic words were mysteriously replaced by text from the article links being added in a completely separate section of that main page:
 * mainpage-leftcolumn-start
 * SITENAME
 * NUMBEROFARTICLES
 * createbox
 * mainpage-endcolumn
 * mainpage-rightcolumn-start
 * NOTOC
 * NOEDITSECTION

Once again the expedient fix is to add the magic word __NOWYSIWYG__ to that page to guard against future disruption but that is not as good as figuring out why the new editor is being so disruptive in the first place.


 * This could very well be related to the copy and paste known bug mentioned a few posts earlier.

I support the idea of a WYSIWYG editor but in it's current form it is generating extra clean up work. najevi 04:12, 11 June 2009 (UTC)


 * That is extremely odd, and certainly shouldn't be happening. Do you have any idea at what point during editing the magic words got corrupted? 14:05, 11 June 2009 (UTC)

The lines I'd edited (on a freshly created new wiki main page) before noticing this bug were:
 * 1) (fill in topic)
 * 2) (Month) (Year)
 * 3) the table of "Add link to article here" within Contents section

I used the "Insert/Edit link" tool from the new editor toolbar to insert the internal links for about ten articles. I do recall discovering that if I left the "Link text" input box blank then the default text that would appear when I next checked the article link properties was (of course) the article title. Whether that is significant or not I do not know. najevi 14:26, 11 June 2009 (UTC)


 * Thanks for the steps - we haven't been able to reproduce it so far, unfortunately. 11:11, 15 June 2009 (UTC)

Spell check is deficient compared to source editor spell check
One of two things is happening. Either the new editor is not picking up on certain spelling errors by using the red underline or after saving an article from within the new editor it is injecting spelling errors. (I doubt it is the later!)

It does highlight mis-spelled words but it seems to overlook some spelling errors with no apparent pattern that I can detect.

I suppose it could also be that the spell checker parsing is somehow slower in the new editor. Bottom line is that the source editor has superior ability to highlight mis-spelled words in real time. najevi 05:16, 11 June 2009 (UTC)


 * What browser are you seeing this issue on? 14:08, 11 June 2009 (UTC)

Firefox 3.0.10 The red underlines for spelling errors does not appear until after I press the preview button. This is different than the WML source text editor in which these red underlines appear real time while entering text for an article. najevi 14:28, 11 June 2009 (UTC)


 * This may be a limitation of the editor itself - I'll bring it up and see if I can find out more. 15:44, 11 June 2009 (UTC)

Article with section edit links requires NOWYSIWYG magic word in each section
The magic word __NOWYSIWYG__ is supposed to suppress the new rich text editor and instead use the WML source editor by default. That does work if the page is opened for edit but not if only one section of that article is opened for edit.

A clumsy workaround is to add __NOWYSIWYG__ in every section but I doubt that this is desirable. najevi 05:49, 11 June 2009 (UTC)


 * Certainly not desirable! As far as I recall a NOWYSIWYG magic word anywhere on the page is supposed to affect section edits. It's possible this functionality broke during development - I will bring it up. 14:10, 11 June 2009 (UTC)

Translate to Dutch
Hi,

If required, I'd like to translate the visual editor to Dutch. Just leave me a message if I have to do it. Tedjuh10 - Talk 16:08, 11 June 2009 (UTC)

Defaul editor
I think it would be more effective if edit window was adjusted the same way (source view or WYSIWYG) as the user preferred earlier. Sometimes make many edits that require source editing, sometimes — WYSIWYG is enough. It annoying to switch every time to source. — Hellerick 14:16, 15 June 2009 (UTC)


 * If you think that switching is annoying every time, you can disable rich text editing via user preferences, under the "Editing" tab; but I'm not entirely sure what you mean by "adjusted the same wa as the user preferred earlier". Do you mean have rich text enabled or disabled depending on the user's prior preference before the release of the editor? Wjxhuang,  the 888th Avatar  {Talk} 15:22, 15 June 2009 (UTC)


 * I mean if the previous edit was made in the source mode, then the next time the editor should open in the source mode; and if it was made in WYSIWYG mode, then the editor should open in WYSIWYG mode. It's better than to go to your preferences several times a day. — Hellerick 16:05, 15 June 2009 (UTC)

Compatibility problems
The rich editor does not work at all for Opera, and there are several bugs on Internet Explorer 8; it's like a completely different editor.--D. (talk · contr) 15:31, 15 June 2009 (UTC)


 * I can confirm a lot of bugs for Internet Explorer; the editor is a thin band of grey and weirdness compared to what it is supposed to be. It actually reminds me of the bad old Office XP. I don't have Opera though, don't know about that. Wjxhuang,  the 888th Avatar  {Talk} 15:35, 15 June 2009 (UTC)

It also does not work for Google Chrome: it simply doesn't appear just like for Opera. --D. (talk · contr) 15:55, 15 June 2009 (UTC)


 * Indeed, Chrome and Opera are not currently supported browsers. It is entirely possibly they will become so in the future, but at the moment we are primarily aiming at Firefox and Internet Explorer.
 * Can you provide a screenshot of the IE8 issue? 16:42, 15 June 2009 (UTC)


 * The new editor is completely non-functional for me in IE8 (it has the same behaviour in both normal and compatibility modes): I get a number of alert boxes saying "Unknown toolbar item...", and then there's just the loading animation, no editor appears. (Screenshot) --Onteron (talk) 17:07, 15 June 2009 (UTC)
 * What Onteron says. You get bunch of alerts. The editor appears after all alerts have passed on Windows XP. The wikitext source makes the coding a huge mess. --D. (talk · contr) 18:01, 15 June 2009 (UTC)


 * We can confirm this and will get it fixed as soon as possible. 18:25, 15 June 2009 (UTC)


 * You should mention the supported browsers at Help:New editor. --Justme2 21:16, 15 June 2009 (UTC)


 * I've added it to the end of the page. In other news, IE8 should now be fixed. Please let us know if you encounter any further such issues! 15:47, 16 June 2009 (UTC)
 * Yes the editor loads for me now. Thanks --Onteron (talk) 16:40, 16 June 2009 (UTC)

Template transclusion
On the Domo Wiki, we tend to use templates for tables, specifically when creating several rows. It's easier and shorter to type than the full wiki code. On the title article, when someone wants to edit it, this is what happens. This eventually renders the page incorrectly. When you view its wikitext source, the first row template is on a different line. If you switch back to WYSIWYG mode, it then renders like that. --D. (talk · contr) 21:46, 15 June 2009 (UTC)


 * Thank you for bringing this up - I shall pass it on for investigation. 16:01, 16 June 2009 (UTC)

"Wikitext source" problem in IE8
In IE8, I click the "wikitext source" button, and it displays HTML, not wikitext. -- LordTBT Talk! 23:03, 15 June 2009 (UTC)


 * This issue should now be fixed. 15:57, 16 June 2009 (UTC)

What's this? I seem to see HTML in the bottom box while on Firefox. And it appears to me that they have two editors. ~Joey~ ^Talk^  17:13, 16 June 2009 (UTC)
 * This has been fixed now, but any wiki with WikiED will have some problems with the editor. A fix is shown on that wiki's JS. <font color="Green">~Joey~  <font color="Green">^Talk^  05:56, 19 June 2009 (UTC)
 * The issue is fixed, however when it is in wikitext source-mode, the icon still says "wikitext source" in the tooltip...shouldn't it say "return to visual editor" ? -- <font color="Green">LordTBT <font color="Green" size="2">Talk! 19:19, 16 June 2009 (UTC)


 * Good spot, I've passed it on. 16:00, 22 June 2009 (UTC)

Occasional access to the new editor for user who prefer the old editor
I tried for a few days to use the new editor but found I was wasting too much time fixing anomalies that it injected into the page. I also noted that the new rich text editor takes longer to load than the old source editor. So I went into preferences and disabled the new editor.


 * From time to time I think it might be a good idea to see how a page will handle being opened and edited by a contributor using the new editor.

At the present time I cannot do this without laboriously opening my preferences and re-enabling the new editor. Trying the edit and then revisiting my preferences to disable the new editor again.


 * It might be a good idea to have a button added to the source editor that allows the user to switch to the rich text editor however, if adding this feature will only cause the source editor to load as slowly as the new editor loads then I'd rather not have this convenience.

najevi 14:16, 16 June 2009 (UTC)


 * That sounds like a great idea. Wjxhuang,  the 888th Avatar  {Talk} 14:27, 16 June 2009 (UTC)


 * We're adding some parameters that you can attach to the page URL to quickly switch modes, which may aid you here. 15:53, 16 June 2009 (UTC)


 * The parameters are now live -  - add one of those to the end of an editing URL (this will only work on namespaces where the new editor is already enabled). For example,   would force it into using the old editor.  12:24, 19 June 2009 (UTC)

Transcluded Template Bug from Central
While in the editor mode of a page that has a template trasncluded from Central, when you hover over the teamplate and scroll to the bottom you get a few lines of text that say ' NewPP limit report Preprocessor node count: 5/1000000 Post-expand include size: 0/2097152 bytes Template argument size: 0/2097152 bytes Expensive parser function count: 0/100 --> '. Examples. :) <font color="Green">~Joey~  <font color="Green">^Talk^  16:48, 16 June 2009 (UTC)


 * Very good spot, thanks! 12:33, 19 June 2009 (UTC)

No help link
I remember seeing a help link at some point while using the new editor, but now I don't see it. I think maybe it was in an early "don't show this again" dialog box, or something similar.

Please keep a help link permanently at the bottom of the new editor. Otherwise the new editor will exasperate new editors. I am an experienced editor here and at Wikipedia, and there are many things that baffle me about the new editor. --Timeshifter 17:45, 16 June 2009 (UTC)


 * You're doing it wrong. The rich text editor is making editing easier for new users, and since you aren't one, maybe you shouldn't be using it? ;-P -- ◄mendel► 21:29, 16 June 2009 (UTC)
 * Of course. Insert epiphany here. Now I see the meaning of life... ;) --Timeshifter 00:11, 17 June 2009 (UTC)


 * It's a fair point - I would like to get a more permanent link to the help page on there eventually. It's something we're looking at. 11:53, 17 June 2009 (UTC)

Code view, plain text view, and rich text view
Code view, plain text view, and rich text view. These are phrases people are used to from Google Mail, Yahoo Mail, etc..

In Google Mail and Yahoo Mail there are alternating links for "plain text" and "rich text" to toggle rich text editing on and off.

In Wikia's new editor there is no labeled link to change views. One has to get lucky and happen to run one's cursor over the right-most icon in the upper toolbar, and then be able to decipher the unfamiliar phrase "wikitext source".

I have no idea what "visual view" and "code view" does at the bottom of the edit window. See the previous section concerning the need for a help link permanently at the bottom of the edit window. It should be labeled "help".

The new editor has a lot of potential, but it completely lacks in help links, help forum links, and other means of rapid community support. This is a problem in general with Wikia, too. There needs to be a "Central forums" link in the left sidebar of every page on every wiki. Linked to this forum index:
 * http://www.wikia.com/wiki/Forum:Index

People want rapid help, or most people leave immediately. They want to leave a message somewhere, and come back and find an immediate answer. That is just how most people are, and I see no reason not to accommodate them.

A really advanced system would have one of those draggable question marks one could drop on any icon in the toolbar, and a dialog box would come up and explain that tool a little. A link for more info on that specific tool would also be in that dialog box. That would be the ideal. Truly instant help. --Timeshifter 18:08, 16 June 2009 (UTC)


 * That's some great feedback, thanks. The idea of making sure we use more consistent naming is certainly a good one. I will pass it on! 11:58, 17 June 2009 (UTC)

Unsupported placeholder type bug
This bug occurs once in a while. Here's the example. The code looks like:

Before

After

Does the development team realise this bug? Do you know what causes it?

I will file a detailed bug report if no one report this before. --MyBrute Resource Center@Ronga 16:43, 18 June 2009 (UTC)


 * We have seen it before, but the cause of it then was fixed. I've reopened the bug, for it to be looked at again. Do you have specific steps to reproduce? 13:05, 19 June 2009 (UTC)

No line wrap for ref tag and other similar ones, breaking the table
Try to edit this sample table and see how it looks:

The ref tag doesn't respect the max width of the table and doesn't wrap line when it's too long. --MyBrute Resource Center@Ronga 17:01, 18 June 2009 (UTC)


 * I see it too. I fear it may be difficult to fix, but we have plans to support ref tags in a better fashion in the future. 13:10, 19 June 2009 (UTC)

Bugs in code handling, cell properties, mouse pointer (arrow key navigation)
Take a look at this edit.

The first bug  The second bug I tried to select the whole column, right click and select cell properties, change the cell color of the whole column.
 * Before: <section begin=pet_detail1 />
 * After: &lt;section begin=pet_detail1 /&gt;
 * Bug: The visual editor interferes the existing codes stored in this page, and nullify them.

However the visual editor does it wrong and put this code for every row instead: Note the !. It is to indicate that this is the header row. It shouldn't use ! for cells which are not headers.
 * !bgcolor="#ffff00"|20

The third bug It happens when you try to navigate a table with headers by arrow keys.

Step: Actual result: The mosue pointer loses focus and will jump outside of the table. --MyBrute Resource Center@Ronga 17:26, 18 June 2009 (UTC)
 * 1) Move your mouse pointer to the header row, as an example
 * 2) Press the down arrow to go to the second row


 * First one: definitely a bug. Will report!
 * Second one: not a bug, to be honest. When you select the column and click properties, it takes the properties of the first box selected and puts those in the options. If you do the same edit again, you'll see it selects "Cell type: header"
 * Third one: I cannot reproduce this one, unfortunately. What browser is this? If I'm reading right, I should just place the cursor in the header row and press down? That worked okay for me in the pet template.
 * 12:54, 19 June 2009 (UTC)

Line hasn't been changed is marked as "changed"
OK take a look at this diff.

The user is using new visual editor to edit.

Note the first colored line. There is no change at all. Still the color highlight is present on that line.

That diff is simple so it's okay. Imagine if the user takes a lot of changes in one go and there are so many false positives appearing when you are checking the changes some anon made. It becomes a headache. It makes checking for diffs difficult, especially if we are working with tables. --MyBrute Resource Center@Ronga 18:01, 18 June 2009 (UTC)


 * Understood. As far as I know, it's due to differences between "types" of spaces - the new editor makes them more consistent, even though you might not notice anything in the text (or even when viewing the page in source mode). The main way they get introduced is via copying and pasting from other sources. I am not sure that this is a solvable issue, but I will bring it up. 12:44, 19 June 2009 (UTC)

Article and discussion links disappear after clicking edit button
This poses a problem because I sometimes will open the article in a separate tab in order to see what the article looks like normally while I am editing, or thinking about what to edit.

I also sometimes want to comment or ask questions while editing.

Sometimes I just want to go back to the article, and to bail out of editing without doing any more editing. And I don't want to have to use the back button on the browser toolbar. That can take a long time, and can be risky. --Timeshifter 23:51, 18 June 2009 (UTC)


 * Thanks - this is an situation we are aware of, and are looking at ways to improve. We'd rather not reintroduce the entire header area for editing with FCK, but it's certainly an issue I personally understand. 12:40, 19 June 2009 (UTC)

Can't right-click cut, copy, or paste in new editor
I am using Firefox 3.5

OK, I finally tried to do some editing in the new editor. Up to now I have been clicking the Wikitext Source button to edit in the wikitext editor.

In the new editor I selected some text and a wikilink. When I tried to right-click and cut out that text and wikilink in order to paste it elsewhere I got this message in a dialog box:


 * Your browser security settings don't permit the editor to automatically execute cutting operations. Please use the keyboard for that (Ctrl+X).

It's funny. I am able to right-click and copy that dialog-box message and paste it here, but I can't right-click and copy/cut/paste inside the new editor.

I am able to copy/cut/paste from the browser edit menu though. Keyboard commands also work. Ctrl+X works for cutting. Ctrl+V works for pasting.

I can't figure out what in my security settings could be causing the right-click problems in the new editor.

Trying to right-click paste produces this dialog box text:


 * Because of your browser security settings, the editor is not able to access your clipboard data directly. You are required to paste it again in this window.


 * Please paste inside the following box using the keyboard (Ctrl+V) and hit OK.

But I can paste into that special dialog-box window by using the browser edit menu. I can also paste directly into the new editor by using the browser edit menu. --Timeshifter 23:48, 18 June 2009 (UTC)

Firefox rich text editing
I checked the rich text editing again at my Google Mail and Yahoo Mail accounts. I have no problem there when I go to the reply window for a message, and then right-click cut/copy/paste in their rich-text editing windows.

I did some more research and found these pages and threads:
 * mozillazine.org thread - Unable to paste from clipboard.
 * mozillazine.org - Granting JavaScript access to the clipboard.
 * Wikipedia: Online rich-text editor.
 * geniisoft.com - A list of online rich text editors updated regularly.


 * mozillazine.org - Rich text editing has this:


 * Some sites feature rich text editors that allow you to easily format (bold, italicize, etc.) text. However, some sites have not been coded to work with Firefox and Mozilla Suite's Midas feature; they only work in Internet Explorer.


 * mozillazine.org - Midas has this:


 * Midas is a rich text editor built into Firefox that is similar to an editor built in to Microsoft Internet Explorer. Midas can be turned on by setting the designMode property of an HTML document to "on". This can be done via JavaScript. With Midas enabled, the page becomes completely editable by the user and a whole set of other JavaScript commands become available.

My theory is that the new editor has not been made fully compatible with Firefox. It looks like Google Mail and Yahoo Mail have done so. Maybe it can be figured out how they are doing so.


 * argotvisual.net - Enable Firefox paste functionality - a complicated solution via creating and/or editing the user.js file.

The last link seems to use info found at Granting JavaScript access to the clipboard. That page has even more options. --Timeshifter 02:54, 19 June 2009 (UTC)


 * The reason the editor is filled with so many bugs is not because Wikia has no knowledge of how rich text editors work. There are so many rich text editors on the web; that's easy. The reason for all these bugs on Wikia with this editor is because the designers have tried to make it compatible with wikitext and with all the extensions that Wikia has given us. So the best thing to do now is not to suggest this type of thing, but to report all bugs and compatibility issues. By the way, the reason it might not be working so well for your version of Firefox is because your version of Firefox is not a release version. The last formal release of Firefox is 3.0, which is fully supported and works fine. Wjxhuang,  the 888th Avatar  {Talk} 09:15, 19 June 2009 (UTC)


 * The pasting issue - yes, this really is/was a technical restriction. We've not chatted about it recently, so I'll bring it up in case anything has changed, or we can alter the behaviour.
 * Regarding Firefox 3.5, we'll be supporting this directly very soon. It's our primary browser to develop for :) 12:10, 19 June 2009 (UTC)

Adding points and spaces
Another known and annoying bug with this thing, it likes to magically add spaces for no apparent reason by itself. And now, it also decided to start adding (*)s to multiple lines by itself. From that link, all I did was add "test" to one parameter and "foobar" to another, but the editor completely changes the page. Please fix these issues, thanks. <font color="Green">~Joey~ <font color="Green">^Talk^  01:14, 19 June 2009 (UTC)
 * Hmm it also seems to have changed the format of the template I changed, by separating it onto lines with each parameter numbered. Grr, that's not how I changed it, so I am not happy when I see this happening on multiple pages and someone has to 're-edit' every page a RTE user edits :( <font color="Green">~Joey~  <font color="Green">^Talk^  01:21, 19 June 2009 (UTC)


 * This happened on my user page on Avatar Wiki, to the point where I simply used the magic word to disable it for the page because it was adding spaces in the most random places possible. Wjxhuang,  the 888th Avatar  {Talk} 09:03, 19 June 2009 (UTC)

Thanks for the report - I'll pass this on and get it worked on quickly. 12:15, 19 June 2009 (UTC)

Undo fail - blanking
The editor appears to have difficulties undoing edits, which is a serious bug. As seen here, you'll notice The 888th Avatar and I both undid the same edit, yet because he had the editor enabled, his undo actually blanked a lot of content. Both his edits there demonstrate a bug with undos and the editor. Thanks. <font color="Green">~Joey~ <font color="Green">^Talk^  07:58, 19 June 2009 (UTC)


 * Oh, the bad memories... yeah, I've noticed in general (not just this case) that undos stuff up a little. When it works, it adds things that were never there. Also, when it works it is quite slow to save the page, and the edit often shows up on the recent changes feed before the article is actually loaded in my browser again. When it doesn't this type of error happens. :( Wjxhuang,  the 888th Avatar  {Talk} 09:02, 19 June 2009 (UTC)
 * Actually, the slowness of the loading happens to me without the editor, it's something different. <font color="Green">~Joey~  <font color="Green">^Talk^  09:24, 19 June 2009 (UTC)

Thanks for the report - the techs have fixed the table removal issue (which was due to the indent). I've asked for it to go live as soon as possible. 12:00, 19 June 2009 (UTC)


 * Joeyaa: I know what I'm saying, the slowness was only happening for me with the new editor. Wjxhuang,  the 888th Avatar  {Talk} 12:11, 19 June 2009 (UTC)


 * The speed of the editor is something we're working on. Part of the issue is waiting for the next release of the editor it is based upon, FCKeditor (soon to become CKEditor for possibly obvious reasons). 16:05, 22 June 2009 (UTC)

style template gets autoremoved
See http://guildwars.wikia.com/index.php?title=RTE_bug&diff=1488721&oldid=1488720 for a demonstration. Would it work to turn the RTE off with a keyword in the template? Probably not, right? And have a look at http://guildwars.wikia.com/index.php?title=Ranger_skills_quick_reference&action=history, the anon is myself trying to edit the page, which fails spectaculraly, and then trying to revert my edit, which fails as well; and the first edit was in source mode, too, so even that doesn't help. -- ◄mendel► 12:57, 19 June 2009 (UTC)


 * I can confirm the template removal issue, and I have passed it on. Thanks! 13:18, 19 June 2009 (UTC)

Templates - non display of (non existant) template place holders
It now appears that we can nolonger get a red-link for templates that are placed on pages ready for template creation. In the past when was added to a page you got a 'link' ready for the template to be created and then displayed. Now it no longer displays you cannot see which pages have them included in readiness for there creation. (thus reducing the chance of others creating them). Another backwards step from the new Visual editor implementation by the look even if editors have opted out in preferences!

Note: this action is with the Visual Editor turned off. (i'm not wasting my time on it till it works in a usable manner that does not slow down editing and add more errors than my poor tying already creates) !! Having to do umpteen mouse clicks instead of typing a few {{ or [[ to add links and templates is not productive (like predictive text on mobile phones giving completely useless rubbish).

I assume from some of the earlier discussions / posts the new Editor thing must be why I've had several of IP editors recently adding blank lines to pages, were as previously the odd IP one removed extra blank lines from some sections. (note they are not adding any other content) so must be opening the page and then on close the 'Wikia system' is adding the extra characters.

Can this new editor be turned off (completely) for all users of a individual wiki by default ?

- (A not impressed by this new 'feature') - BulldozerD11 13:55, 19 June 2009 (UTC)


 * Yes, you can do so via Special:Contact. However, the template issue is because you are trying to type wikitext into the WYSIWYG mode of the editor - currently we don't support that, and the templates get wrapped in nowiki tags. You can do it using wikitext by switching to source mode (the icon at the far right). However, it's something we are looking at changing for very common pieces of wikitext, such as links, bold, etc. {{User:Kirkburn/Sig}} 14:16, 19 June 2009 (UTC)


 * Thanks for reply Kirkburn, But NOTE I have the editor turned OFF, but nolonger get the {{Some template}} which displayed as a red link "Template:Some template" till it is create, which allowed; A - users to see a template is needed, B - the name of proposed template (thus the naming convention becomes pretty obvious to users), C - I can see which pages Ive added it to without going to edit mode, D - I dont need to trawl through Specialpages:wanted templates to remind myself of some of the proposed templates. So when im in a article that started as a stub if i've got enough related articles created to make a template woth starting its easyier, as then when filling inthe links the predictive links (when it worked better) offers you the link titles with less mistakes, than guessing title options.


 * Templates like {{reflist}} which exist are hidden which is fine and logical as its code is designed to show information from other sources (If its present).


 * I'll see if the other users are using the new WYSIWYG (or the what wikia thinks you need) Editor, as my preference would be to turn it off on the Tractors Wiki, till it is Functional as learning basic wiki Codings not hard, just look at a page and try it out with preview & a bit of C&P works for basic templates. if 100's of thousands of wikipedia editors can learn it, its not that hard. Creating complex templates is different matter.


 * Tables are the feature most usefully 'automated' But the reports of problems above are enough to convince me to steer clear till its fixed as cleaning up 'Bad' tables is a pain & most of my common tables are placed on templates and transcluded into the page (after the parser update fixed some of the wikipedia template import issues i had before) a handy edit button set in the corner linking to the table for editing. So a Copy & Paste from a blank sample creates one in the required format after clicking on the handy RED link left in the article to the template page.

PS: I note while editing this the Wikia spotlight adverts are acting up and appearing over the edit page on the edit quick links bit following using prewiew button, rendering the links unusable - BulldozerD11 16:47, 19 June 2009 (UTC)


 * Sorry, I misunderstood the first time about the redlink template issue: I agree, this is broken - the links literally are missing from articles, which should not be happening. We'll get that fixed. {{User:Kirkburn/Sig}} 16:13, 22 June 2009 (UTC)


 * Looks like this template red link bug is now cleared - thanks BulldozerD11 21:30, 2 July 2009 (UTC)

line breaks around div tags go away
The RTE eliminates linebreaks near div tags, which implicitly removes p tags, which breaks formatting. -- ◄mendel► 23:45, 20 June 2009 (UTC)


 * I think I noticed this the same day as you - I was doing some testing on other stuff and noticed it occurring when switching editing modes. It shouldn't be happening, and a bug has been filed. Thanks! 16:14, 22 June 2009 (UTC)

more bugs
See : The RTE still removes some newlines around div tags, but adds up to 4 linebreaks near others. It also removes hotlinked images, i.e those that were added by simply writing the image URL into the wikitext.

I am sorely disappointed that after more than 10 days after deployment (this wasn't a beta) I still have to revert bugs like that. -- ◄mendel► 09:02, 26 June 2009 (UTC)


 * I've reproduced the image removal issue, we'll get that fixed. The linebreak addition/removal is still being looked into. 14:13, 3 July 2009 (UTC)


 * Note: for image URLs, make sure not to include the release name, asthose links are temporary. Instead of, use    15:33, 3 July 2009 (UTC)

Visual editor user talk page problem
Since the new visual editor appeared signatures are not dispalying on user talk page See here and : indents not functioning. Note: both User:Scoty6776 & I are NOT using the Visual Editor, but posts were fine prior to this being released. Is this another Bug in the 'Magic' WYSIWYG (not) editor ? (strange but my posts work fine on central ? ) - BulldozerD11 20:10, 26 June 2009 (UTC)
 * Not a RTE issue, there was a &lt;nowiki> tag hidden in the page text. -- ◄mendel► 23:56, 26 June 2009 (UTC)
 * Apologies for me missing the obvious, should have used the full pair twice then - OOPS - thanks for fix, thought it odd my sig worked on here on here, - BulldozerD11 10:07, 27 June 2009 (UTC)

When the RTE chokes, content disappears.
I can't cite the exact situation anymore (I wish I'd thought to check for this thread when it happened), but when the RTE finds some wiki text that it can't understand, it takes huge portions of content out of the page. I didn't know it was doing this at first, but the last time it happened I opened the RTE two or three extra times just to make sure. After that I found the setting in preferences and turned it off just so I could edit that page - and I'm not turning it back on for a long time, except maybe to report the bug. That won't be happening just yet, though; I have something else I came to the forum for (if I can just remember what it was...). --Jesdisciple (talk) 19:54, 27 June 2009 (UTC)


 * That sounds very odd. For future reference, for us to reproduce such errors it's useful to know: what wiki, what page, what the edit was, and what browser you're using. 14:02, 3 July 2009 (UTC)

category editing slowed down a lot by new editor at times
Today I indexed nearly all the people articles and subcategories in this category. It is a category of pages about people. So it is common to index by last name.

Before the new editor I could copy and paste the last name from the title of the section. Now I can't and I have to manually type the names. This greatly increases the time it takes for categorization and indexing.

Before the new editor Wikia used to be like Wikipedia. For example; in Wikipedia if one clicks any of the edit buttons in Barack obama there remains this at the top:


 * Editing Barack Obama (section)

So I can copy and paste from that. I can then easily index:



Manually typing out the name is especially tedious for long names. For example:


 * Jeff Christen-Mitchell

is indexed


 * Christen-Mitchell, Jeff

Multiply by many names. --Timeshifter 09:16, 28 June 2009 (UTC)


 * There is the page URL, but I realise that's not ideal for all cases. We'll discuss it. 13:57, 3 July 2009 (UTC)

RTE is second-guessing us again and fails
RTE removes several line breaks, putting &lt;h2> and &lt;/h2> tags on the same line, which in turn makes the parser insert an additional level of &lt;span> tags (why on earth...), which breaks our .css and makes the headline disappear. -- ◄mendel► 15:19, 29 June 2009 (UTC)


 * This is one clear example of page that needs a __NOWYSIWYG__ tag. In my opinion, not a bug, because is complex formatting. --Ciencia Al Poder (talk) -WikiDex 18:04, 29 June 2009 (UTC)


 * Interesting, I've never seen headings done multiline like that. The space_after issue is fixed, and we're looking into the line break part. 13:50, 3 July 2009 (UTC)
 * "never seen like that" &mdash; what a nice way to put "overly complex" ;-) -- ◄mendel► 13:52, 3 July 2009 (UTC)

Where are curly brackets, noinclude tags, gallery tags, etc?
When I click out of the new editor (rightmost "wikitext source" button) to go back to the old editor, the old editor's wiki-markup quick links are gone (at the bottom of the edit window).

Such as:


 * curly brackets (for templates)
 * noinclude tags
 * includeonly tags
 * gallery tags
 * ref tags
 * and so on:

Wiki markup: –    |   []            undefined   undefined      ""

The above list only shows up on my wiki when I uncheck "Enable Rich Text Editing" in my preferences on that wiki.

I would prefer to still see those wiki-markup quick links when I use the new editor too. I mean when I click out of the new editor to work on the wikitext source directly.

Compare Wikipedia and Wikia sandboxes:

Wikia:
 * http://www.wikia.com/wiki/Wikia:Sandbox - new editor is disabled. Some wiki-markup quick links are seen at the bottom of the edit window.
 * http://cannabis.wikia.com/wiki/User:Timeshifter/Sandbox - new editor is enabled by default for this wiki, and via my preferences.

Wikipedia:
 * http://en.wikipedia.org/wiki/Wikipedia:Sandbox

Click the sandbox edit links and look at the bottom of the edit windows.

In wikipedia the wiki-markup quick links are viewed after clicking "wiki markup" in the "insert" menu under the edit window. --Timeshifter 09:26, 1 July 2009 (UTC)


 * These would be the "edit tools", mentioned on Help:CharInsert. Yes, we currently don't have a way of showing them when using the new editor - it's on our list to look at though. 13:49, 3 July 2009 (UTC)


 * Thanks. I like the long list of wiki-markup insertion links used in wikitravel.org edit windows. Easy one-click access and experimentation. See:
 * http://wikitravel.org/en/Sandbox --Timeshifter 22:43, 4 July 2009 (UTC)

The New Editor.....Not Working
I'll just add here in disapproval of the new editor. I'm having to fix about 50% of the new edits because most of the time the edits are not set for wiki at all, and everytime they do a headline or a link, it sets up a "   " around it. I'm getting tired of deleting them, and the users get annoyed as much as I do. Devilmanozzy 13:27, 3 July 2009 (UTC)


 * We have some fixes for the nowiki stuff coming up - several types of wikitext formatting won't get those tags. The current list we're planning on supporting are:


 * Headings
 * Bold, italic, strikethrough, links, signatures
 * Templates (simple ones)
 * Magic words
 * That will hopefully make life much easier :) 14:00, 3 July 2009 (UTC)


 * "Headings"
 * "Bold, italic, strikethrough, links, signatures"
 * If so, I'll be happy. Devilmanozzy 14:06, 3 July 2009 (UTC)


 * This will be arriving today: Forum:Rich Text Editor and Monaco skin updates - July 15th. 09:10, 15 July 2009 (UTC)

Table wikitext changed by new editor
In one of my sandboxes I formatted a table in my preferred format (in the source editing window of the new editor), and then saved it.

See my preferred format in this diff.

After saving the page though, my formatting was changed. See the edit window for this version of the sandbox:
 * http://cannabis.wikia.com/index.php?title=User:Timeshifter/Sandbox&oldid=12809

When looking at the wikitext via the edit button (and then the "view wikitext" source button) one sees that the wikitext has been changed to a different format. Everything has been put in one column of wikitext.

I much prefer using double vertical lines for cells in a row. Because it is very easy to see the table rows and columns. After saving the table, and then going back to it for further editing it is easier to edit. The rows and columns remain easily identifiable in the wikitext source.

Here is the table in an article after further formatting. --Timeshifter 19:00, 5 July 2009 (UTC)


 * Unfortunately, this is a technical restriction - while we'd love to preserve the "shorthand" style of table formatting, we currently cannot. However, it's something we're looking at working on. 13:58, 6 July 2009 (UTC)

auto-correcting "wrong" HTML breaks page
On this page, we wrap a part of the page with headings in it in a &lt;div> block. When the RTE edits the section above the first heading, it sees the opening &lt;div> tag, but not the section where it is closed, and adds a closing &lt;/div> tag on its own (diff). This breaks the page and the sidebar. Switching from Rich Text to Wikitext mode doesn't help, the only working protection seems to be __WYSIWYG__. -- ◄mendel► 15:09, 12 July 2009 (UTC)


 * Thanks, I've passed it on. 15:22, 13 July 2009 (UTC)


 * Unfortunately so far, we've not been able to work out a solution for this - it's difficult for us to detect when the browser tries to close open tags (as I'm told, that's what's occurring). At the moment, the best solution to avoid it entirely is the NOWYSIWYG tag, but we're going to keep thinking about other possible solutions. 14:34, 16 July 2009 (UTC)

no page navigation in edit mode
This is a bug I have not reported earlier because I am usualyl not using the RTE.

Using Monaco/the RTE editor, the edit page is missing the page navigation (edit/history/etc.) and the masthead. I've tried this on GuildWiki and on w:c:communitytest. This behaviour is bad because sometimes, several previews down, I decide an approach is not working and hit the edit tab to request a "fresh" start. Also, sometimes I need to consult the history or the talkpage, and I could, with the link available, just open it in a new tab; this is no longer possible.

Please make the page navigation available again when editing. -- ◄mendel► 15:09, 12 July 2009 (UTC)


 * This is something we're concious of, and hope to come up with a solution for. No news yet, though. 15:25, 13 July 2009 (UTC)

problem with spaces
see: Forum:Problem with some users when they try and use the space

-- Semaj draehs - any replies to my Talk page  10:09, 16 July 2009 (UTC)


 * Basically, what Joey said is correct - it's converting spaces to a single type. Do you have any example diffs? 11:20, 16 July 2009 (UTC)

and are the two examples I could find.

-- Semaj draehs - any replies to my Talk page  12:12, 16 July 2009 (UTC)


 * Hmm, that's a different issue - very strange. Could be browser dependant. I'll pass it on the the techs to see if they have any ideas. 12:40, 16 July 2009 (UTC)


 * Okay, it appears to be "capital" spaces - e.g. typing a space while pressing shift, or with caps lock on. We're looking into it :) 13:52, 16 July 2009 (UTC)

Is this still being looked into? I have the same problem on the Hitman Wiki, and it makes checking diffs very difficult. — Derple (talk) 06:28, 20 July 2009 (UTC)

Templates
Not sure whether this has already been reported (this page is getting a bit unwieldy) - the RTE converts template syntax for unnamed parameters from the format to This causes problems if one of the template parameters is a list or something similar, as the parser requires the asterisk (in case of an unordered list) to be the first character in the line for it to be converted into a list item. For example: is converted to The first works just fine, the second will result in list 1 not being an actual list item (the asterisk will be displayed as such in the article).

Another example can be seen here; "Riverboat Landing" is no longer displayed as a list item after the RTE conversion but as a standard line with an asterisk in front. -- Porter21 (talk) 11:08, 19 July 2009 (UTC)


 * The new editor does a similar thing with table wikitext. See higher up on this talk page. --Timeshifter 10:53, 20 July 2009 (UTC)
 * Well, I was primarily referring to the removal of the newline within the template call, not the conversion from short- to longhand. While I agree that the latter seems a bit superfluous, it doesn't change the appearance of the actual article - the removal of the newline does. I've clarified my initial post a bit. -- Porter21 (talk) 12:18, 20 July 2009 (UTC)


 * OK. There is a similarity in how the new editor is treating vertical bars/pipes in both the table template in my post, and the column template in your post. The new editor is moving each bar to the beginning of a new line. See:
 * Template:Columns
 * Help:Tables


 * I found out what may be part of the reason why from a talk section in another thread. Mendel wrote: "...the problem is that the RTE doesn't see the wikitext, it is a HTML editor and gets fed HTML from the server, and the server re-makes the wikitext from that (and some hints)."


 * It seems like a lot of problems are from how the new editor treats templates. If it is recreating them each time this could explain a lot of problems. Maybe the new editor needs a "hint" not to change template wikitext.


 * It should be instructed anytime it sees template brackets to pull up the wikitext, and not the HTML. I don't see how it would know to recreate the template unless it first identifies the presence of a template by the curly brackets.


 * So I think the new editor should only be allowed to recreate the simple stuff in wikitext (anything not within curly brackets) from the HTML. It should not be allowed to recreate template wikitext from HTML. --Timeshifter 10:09, 21 July 2009 (UTC)

Number added to external link name
Another problem. Please don't shoot the messenger! Please see this diff for a photo page. I did not add that number "4" to the link name. The new editor added that. --Timeshifter 11:07, 20 July 2009 (UTC)

The New Visual Editor confuses new users
We have had two new users actually attempt to use the RTE for something most old users have managed: to make their userpage display information about their role-playing game character and some userboxes, and spend enough time on this endeavour to leave evidence of spectacular failure of the RTE to make their task easier.

My conclusion from watching this is that the RTE isn't reaching its goal: users still have to learn a lot to use it well, but they learn how to cope with the RTE's limitations rather than learn something about wikicode, which is knowledge that would serve them much better in the long term, and actually helps on acquiring other computer-related skills such as learning HTML or programming. I used to be undecided about the RTE, feeling that advantages and disadvantages were balanced, especially with some bug fixes in the offing, but I have now realized that this is not the case, and never will be: using a HTML editor to edit Wikicode is always going to be somewhat rocky.

To see for yourself how horribly hard the RTE makes jobs that were once easy, see these screenshots:
 * w:c:guildwars:GuildWiki:Userbox_gallery is a display of the userboxes available on our wiki. Using the old editor, you'd just copy the code for the box you want to the clipboard, paste it on your userpage, and you'd have a nice box.
 * I try to do something similar with the RTE. This is marking the content, I purposely tried getting the userbox itself because I already knew copying and pasting the code alone would be weird.
 * Before I get to paste, the RTE makes me click away two dialogues asking for access to the clipboard (not shown; the old editor never required that). The result after pasting looks promising.
 * Trying to save, the editor detects an external link (where??), and see what has become of the page source.
 * The result looks pitiful, the copied images are gone, and the template call has been copied with its link that the gallery page placed, but also with the userbox.
 * The RTE refuses to edit the page in rich text mode now.

The test page is at w:c:guildwars:User:M.mendel/copypasting_RTE.

Conclusion: The RTE is only doing well at very simple tasks, but they are not that difficult to learn using the old editor. At some point, which is hard to predict, it lets its users run into what amounts a brick wall, where they have to either learn a lot, or give up on achieving complex tasks. The old editor requires some learning from the start, but much knowledge can be acquired just by observing how others did it, and there is no "brick wall" learning step involved. Also, all the documentation available for wikicode is useful for that.

-- ◄mendel► 11:36, 23 July 2009 (UTC)

Mediawiki may be part of the problem with templates
I was trying to figure out a baffling problem with this Wikimedia Commons template:
 * http://commons.wikimedia.org/wiki/Template:Categorise

See: commons:User:Timeshifter/Sandbox 2

I discovered that the MediaWiki software's way of dealing with some nested templates caused this particular problem.

So, not all the problems with templates may be caused by how the WYSIWYG editor here deals with templates.

By the way, I really like how the WYSIWYG editor helps with some things. So I hope Wikia perseveres with improving it.

I think a simple solution to many of the problems is to add 2 edit links. One for the new editor and one for the old one. Then over time we will know which editor to choose for various tasks. --Timeshifter 17:26, 25 July 2009 (UTC)

A social-oriented approach (I mean we are talking about wikis, right?)
I've been pondering about the visual editor thing quite allot and for a long time. Some of you may remember that I raised this issue in one of the feature requests posts here way back here it is. I thought then, and I still think now that a visual editor in a wiki is a step backward, not forward, but on the other hand is necessary because the MediaWiki markup may intimidate new users. Personally I find it much easier to strike the equal key two times to start a second level header then to have to move my hand from the keyboard to the mouse, then move the mouse to the H2 button and so on, but I know that many people would not agree with me on that. However, the real dilemma here is really with macros.

So first of all I think we should distinguish between simple macros that just change the font size or background color, etc, to more complicated macros. For the first kind, I think we should not use macros at all with the visual editor, but rather use CSS-styles that can be selected from a pull-down menu.

As to more complicated macros I suggest a social-oriented approach. What this means is that the "power users" will put the more complicated stuff into the pages, but in a way that will still enable "simple users" to edit the text content with a visual editor. This can be done for example, by using an extension called "editme", so if I write,

some text

It will make the text inside the tag act like an editable subsection (that is an edit button will appear for it and will enable to edit it in a visual editor box).

In this way I can do this (without the visual editor):

And what will appear is "enter your text here" in a fancy text, but with an edit button as well so that users can edit just the text. --Oshani 19:05, 25 July 2009 (UTC)