This Forum has been archived

Visit the new Forums
Forums: Index Watercooler New Visual Editor: Problems and Suggestions
FANDOM's forums are a place for the community to help other members.
To contact staff directly or to report bugs, please use Special:Contact.

50px-Replacement filing cabinet.svg

Note: This topic has been unedited for 1055 days. It is considered archived - the discussion is over. Do not add to unless it really needs a response.

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

Template display suggstions

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 {{wiki|finalfantasy|Final Fantasy}} rather than {{Wiki}}

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

'''Level 0''':
* {{bc|Final Fantasy1}}
* {{bc|Final Fantasy2}}
* {{bc|Final Fantasy3}}
* .....
* {{bc|Final Fantasy9}}

It will displays like the following in the visual editor:

Level 0:

  • bc
  • bc
  • bc
  • .....
  • bc

Here is the actual screenshot taken:

Template display

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:

  • {{bc|Final Fantasy1}}
  • {{bc|Final Fantasy2}}
  • {{bc|Final Fantasy3}}
  • .....
  • {{bc|Final Fantasy9}}

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@fandom 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: {{Wiki}}
  • Display it in this way: {{Wiki|finalfantasy|Final Fantasy}}
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. Kirkburn  talk  contr  @fandom  11:54, 27 April 2009 (UTC)

Template display

All entries become "bc" only. What purpose does it serve to new editors? Only confusion!

Here's the complain recently received from my visitors:


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 <pre> ..... </pre> 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.

Ttibot proposition fcktemplates

In an ideal it would also be possible to add in templates :

  • 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).

I'm willing to have a reflexion about it.

Hve a nice day.

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

General suggestions

Some of these requests may be pie-in-the-sky, but I figured I'd give it a shot.

  • Allow PRE to have a right-click menu to make it do <tt> or <code> instead.
  • Allow S to have a right-click menu to make it do <sup> or <sub> 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 &copy; ( © ), &reg; ( ® ), &lt; ( < ), &gt; ( > ), &rarr; ( → ), &larr; ( ← ), etc. Maybe even &#91; ( [ ), &#93; ( ] ), &#123; ( { ), &#124; ( | ), &#125; ( } ), etc.

I'll add more as I think of them.

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 · 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! Kirkburn  talk  contr  @fandom  20:14, 27 April 2009 (UTC)

Table formatting - shorthand or longhand?

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. Kirkburn  talk  contr  @fandom  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). Kirkburn  talk  contr  @fandom  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 some advanced wikitext?

Let's say we put things like in the page:

  • <pre> ..... </pre>
  • <ref> ..... </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)

Belated note: supporting editing these types of wikitext directly is on our list. Kirkburn  talk  contr  @fandom  15:23, 6 August 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 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: 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|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 · contr) 2:44 PM PST 30 Apr 2009

A quick summary of suggestions and notes so far

  • 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 Fixed
  • 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 button_link.png (no dialog mode) Fixed
  • Don't create redundant link format like [[My Brute|My Brute]]
  • Support direct typing the template code like {{stub}}, or other wikitexts that are not available in the toolbox Fixed
  • Allow changing the values and code in the template, reference ( < ref > ) etc. without switching off the visual editor.
  • Allow using visual editor even if the page has HTML comments.

Kirkburn  talk  contr  @fandom  19:03, 10 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 <pre> 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. Kirkburn  talk  contr  @fandom  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:

  1. after the preview button is pressed
  2. after the saved button is pressed

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)

Thanks ... I've been able reproduce it from your sandbox. Will pass it on to the tech team. Kirkburn  talk  contr  @fandom  16:01, 11 June 2009 (UTC)
  • FYI I have an example showing that <pre> blocks can be significantly different from using a space indent. 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 <pre> here, given how it properly treats code as code. Kirkburn  talk  contr  @fandom  10:35, 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? Kirkburn  talk  contr  @fandom  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. Kirkburn  talk  contr  @fandom  15:44, 11 June 2009 (UTC)

Default editor - remember user choice from previous edit?

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)

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. Kirkburn  talk  contr  @fandom  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:

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! Kirkburn  talk  contr  @fandom  11:58, 17 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:

1[1] 2
3 4
  1. This is a very long reference: Forum:New Visual Editor: Problems and Suggestions Forum:New Visual Editor: Problems and Suggestions Forum:New Visual Editor: Problems and Suggestions Forum:New Visual Editor: Problems and Suggestions Forum:New Visual Editor: Problems and Suggestions Forum:New Visual Editor: Problems and Suggestions Forum:New Visual Editor: Problems and Suggestions Forum:New Visual Editor: Problems and Suggestions Forum:New Visual Editor: Problems and Suggestions Forum:New Visual Editor: Problems and Suggestions Forum:New Visual Editor: Problems and Suggestions Forum:New Visual Editor: Problems and Suggestions Forum:New Visual Editor: Problems and Suggestions Forum:New Visual Editor: Problems and Suggestions Forum:New Visual Editor: Problems and Suggestions Forum:New Visual Editor: Problems and Suggestions

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. Kirkburn  talk  contr  @fandom  13:10, 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. Kirkburn  talk  contr  @fandom  12:40, 19 June 2009 (UTC)
I agree it should have the tabs at the top like normal, it can be very confusing how to get back to the original article without performing an edit. It's as if you stepped into a hole with no way to get out. This theme runs through many of the dialogs, where there is no Cancel button. You can click the end X in the upper right but there should always be an unambiguous way to do nothing and return to your previous location. --Kollio 21:49, September 17, 2009 (UTC)

Firefox rich text editing issues and suggestions

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:

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

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 :) Kirkburn  talk  contr  @fandom  12:10, 19 June 2009 (UTC)

I think this is related but when using the rich text function, my Firefox right-click menu is replaced with a clipboard mini-window. I don't want nor do I need that function but I do want my right-click menu and its spell checking functions. Is there a way I can NOT have the stupid clipboard popup happen and instead have my regular right-click menu? 22:35, September 24, 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 wikipedia: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:

[[Category:Presidents of the United States|Obama, Barack]]

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. Kirkburn  talk  contr  @fandom  13:57, 3 July 2009 (UTC)

Where are curly brackets, noinclude tags, gallery tags, etc? [Edittools]

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: {{}} | [] [[]] [[Category:]] #REDIRECT [[]] <s></s> <sup></sup> <sub></sub> <code></code> <blockquote></blockquote> <ref></ref> {{Reflist}} <references/> <includeonly></includeonly> <noinclude></noinclude> {{DEFAULTSORT:}} <nowiki> </nowiki>

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:



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. Kirkburn  talk  contr  @fandom  13:49, 3 July 2009 (UTC)
Thanks. I like the long list of wiki-markup insertion links used in edit windows. Easy one-click access and experimentation. See: --Timeshifter 22:43, 4 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:

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. Kirkburn  talk  contr  @fandom  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 <div> block. When the RTE edits the section above the first heading, it sees the opening <div> tag, but not the section where it is closed, and adds a closing </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. Kirkburn  talk  contr  @fandom  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. Kirkburn  talk  contr  @fandom  14:34, 16 July 2009 (UTC)
Update: the current solution is that for section edits with unclosed tags, the editor falls back to source mode. Kirkburn  talk  contr  @fandom  15:14, 6 August 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. Kirkburn  talk  contr  @fandom  15:25, 13 July 2009 (UTC)

Problem with spaces

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

--Semajdraehs- 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? Kirkburn  talk  contr  @fandom  11:20, 16 July 2009 (UTC)

[1] and [2] are the two examples I could find.

--Semajdraehs- 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. Kirkburn  talk  contr  @fandom  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 :) Kirkburn  talk  contr  @fandom  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)

I've just checked, and this should be fixed and live. For future reference, for non-urgent issues we generally do releases once a week, so it may take around a week for some fixes to appear on the site. Kirkburn  talk  contr  @fandom  14:40, 28 July 2009 (UTC)

Templates converted to longhand

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

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 #Table wikitext changed by new editor 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:
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)

Thanks for the template list issue report - we'll look into it. Keep the feedback coming :) Kirkburn  talk  contr  @fandom  13:42, 29 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)

Thanks for the report - it appears to occur for links that would normally be interwikied (e.g. Wikia, Wikipedia). Will pass it on. Kirkburn  talk  contr  @fandom  15:33, 28 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)

The old editor has a steeper learning curve. So most readers and users hit a brick wall early on if they try to use it. The new editor is becoming more and more similar to other rich-text editing (Google Mail, Yahoo Mail, etc).
So as the new visual editor gets better, and more intuitive, it will pull more people into trying out some editing of wiki pages. Once they try it, many will try out more advanced stuff later on. More people than the number of people who are trying to do advanced stuff now with just the old editor alone.
With the old editor one can't do a simple thing like copying and pasting lists of clickable links from a web page into a wiki page. Or copying and pasting sentences and paragraphs that contain multiple clickable links, and various bold and italic formatting.
I need to do that for many pages. It is much easier to do that copying and pasting with the new editor. Even with the intermediate clipboard. The clipboard seems to be acting like an HTML to wikitext translation point. --Timeshifter 14:10, 27 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:

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)

What exactly are the things you like to have help with?
Your diagnosis of your problem is wrong; your problem is caused by the way MediaWiki handles automatic paragraphs.
Asking new users to choose the right editor for the task means that the new editor has made life more complicated for them, not more simple. I'd rather they learn wikicode than how to decide which editor to use. --◄mendel► 09:46, 26 July 2009 (UTC)
This is an argument similar to that about learning HTML coding versus using WYSIWYG web page editors. I use both. I used WYSIWYG FrontPage for years until it was no longer supported. Now I use Kompozer since it is a free WYSIWYG HTML editor. Free blog sites such as and Google's let editors choose at anytime between visual WYSIWYG editing and HTML editing. I use both. I have blogs on both of those free sites.
How exactly does this apply?: "... problem is caused by the way MediaWiki handles automatic paragraphs." Please explain further. --Timeshifter 18:50, 26 July 2009 (UTC)

More on MediaWiki problems

Please see:

It seems that Mediawiki causes a couple problems. --Timeshifter 15:04, 1 August 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):

 enter your text here

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)

Why do you think that "power users" like to have made their life made more complicated for them so that "normal" users don't have to learn things? Since when has "I want to stay dumb" been an attitude that power users like to support? --◄mendel► 09:48, 26 July 2009 (UTC)
LOL I suppose I deserve to get this kind of reply. The thing is that I find it hard to estimate your level of cynicism to decide weather to reply to this seriously --Oshani 11:44, 26 July 2009 (UTC)
As far as I can tell, the point of the editor is to keep up with the trends on other text writing software/editors. However, so far its not played out well for wikia. Like already noted most people are finding the new editor very hard to use. It wants to be easy, but really the problem is its not simple enough, and too many buttons and images leaves people scratching they heads. I have to tell people how to turn it off all the time. It's really not yeilding the result it was intended to. I understand why they are doing it, but really how long will they push this before just letting it go? Devilmanozzy 03:43, 29 July 2009 (UTC)

(unindent) I think the problem is that there is no choice of which editor to use. One immediately goes to the new editor whenever one clicks the edit button for any section or page. This wastes my time since I usually want the old editor, and have to click through to get to it.

In some cases I want the new editor for certain tasks. But most of the time lately I want the old editor because currently I paste in lots of template code.

I have blogs on and Both of them use Wikia's method of going directly to the WYSIWYG visual editor first. One can then click another link to go to the source editor.

So I can see Wikia's logic in trying to follow their method. But most people coming to Wikia who try to edit probably come from Wikipedia. So in that case the logical thing would be for the old editor to show up first on clicking the edit button. One could then click another link to go to the new visual WYSIWYG editor.

I would prefer a choice at the very beginning. 2 edit buttons. One labeled "Visual" (like WYSIWYG edit window) and one labeled "Wikitext". labels the source editor "HTML" since that is the code edited in that edit window.

By the way, Alexa traffic ranking is currently 19:

Another idea might be to keep the current edit link, and add an icon next to it (unlabeled) to go directly to the wikitext source editor.
Maybe an eyeball or something. To 'eye' the source code. --Timeshifter 18:15, 30 July 2009 (UTC)
A bit a-propos but maybe also a solution - Firefox now have an FckEditor extension. Does anyone know if it can be configured to filter MediaWiki (if it does, then we can just turn off the editor in the wiki itself and use the extension instead) --Oshani 14:25, 3 August 2009 (UTC)
I found this by searching Firefox addons for FckEditor:
I haven't tried it though. --Timeshifter 16:15, 3 August 2009 (UTC)
I think Timeshifter's idea is quite good - it would be quite beneficial to have a choice at the beginning. It is true that many editors have come from Wikipedia and want an interface that they are familiar with. Wookieepedia, for instance, sprang up from a group of Wikipedia editors who wanted to save their articles from the Wikipedia Votes for Deletion process. The rich text editor is better for those who have never touched a wiki. Both groups need to be catered for, and having a choice at the beginning is a valid idea. Wjxhuang, the 888th Avatar {Talk} 01:21, 4 August 2009 (UTC)

Moving templates locks the RTE

I use a laptop with Vista and IE8, and if I try to move a template while not using wikitext, the browser locks up and I have to use CTRL-ALT-DEL to get to Security and force-quit the browser with Task Manager. Not sure if this is a bug or incompatibility that can be fixed with Windows 7. S-984 16:54, 30 July 2009 (UTC)

Can you give me a link to a specific page where you've seen this occur? I'm unable to reproduce it at the moment. Kirkburn  talk  contr  @fandom  12:11, 31 July 2009 (UTC)

Category name length too limited by new editor

The new editor limits the length of the category name. There is no way around this if one clicks "add category".

Only if one approaches category editing from within an edit window is it possible to get around this limitation. And it is not intuitive how to do so.

One has to click "code view" at the bottom of the edit window. Then one can add any category name of any length.

Most people, myself included at first, had no idea that "code view" at the bottom of the edit window was referring to category editing.

Another user had a problem finding the talk page for an article. They were in edit mode.

So a user has a problem, and then looks for the talk page link to ask for help. As at wikipedia. Many people will give up at this point. --Timeshifter 18:20, 2 August 2009 (UTC)

I know of no limit on category length via CategorySelect - can you describe a bit more what exactly you're seeing?
We understand the issue of the page bar not showing on edit pages - we're still considering solutions for that. Kirkburn  talk  contr  @fandom  15:22, 3 August 2009 (UTC)
I just noticed that the problem is different than what I first thought. The problem is that when one pastes in a long category name in the "add category" form it looks like it is being shortened. But it is not. It is the visible part of the entry form that is too short. Same as the edit summary form.
Please see this list of city pages. Many of them have long category names.
If I click "add category" for one of those pages, and try to add a long category name, I may mess up the name because it is difficult to edit the name by scrolling back and forth horizontally in the entry form.
If after saving the category, I notice that I messed it up, then I can't edit the category name without going to a different edit link. It is very confusing to both old and new users.
So I go to the first edit link higher up on the page. Then I try to edit a category name. The form length is too short there too. So then one goes to "code view". Then one can see the full name of the category. But only after scrolling vertically in some cases. --Timeshifter 16:03, 3 August 2009 (UTC)
Okay, I do see what you mean. I'll ask if there's any issue with extending the input area for category names. Kirkburn  talk  contr  @fandom  15:24, 6 August 2009 (UTC)

Wikia becoming too different from Wikipedia

I think it is a mistake to make changes that differentiate Wikia too much from Wikipedia. I came to Wikia because it was like Wikipedia.

Templates are what make Mediawiki wonderful. Blogs don't have this capability. I can make a change to a template that shows up on hundreds of pages. So when the new editor edits templates without permission of the user, then that is different from Wikipedia, and it is discouraging. One has to learn the quirks of the new editor. Very confusing, and very hard to remember and differentiate from Wikipedia's treatment of template code.

Removing the talk and article links (when in edit mode) and moving around familiar links such as "What links here" from the side bar will alienate and confuse many Wikipedia users. The summary window (for edit comments) is now too short compared to Wikipedia. Category editing is completely screwed up in my opinion. Someone asked about it today on my user talk page.

There are many page coding methods used out there. It is unrealistic to expect people to learn yet another one.

For example; forums have different ways to code a URL to make it clickable. Here is one:

[url]web address[/url]

Wikipedia uses a couple ways. It automatically makes web addresses clickable. Another way is to put single brackets around a URL:

[web address]

Google Mail and Yahoo Mail automatically make links clickable too. Their visual editor is much easier to use compared to Wikia's visual editor. This is due mainly due to the added step of the intermediate clipboard. It is very confusing to many people. It is one more thing to learn. It is very useful, but very difficult at times.

My point is that the new editor would be much more appreciated if it were additive, and not mandatory for unregistered users. It now acts like a filter to block the "uninitiated" from Wikia.

If the new editor were optional, then it would be additive and much more welcome. If it were just another icon on the old editor toolbar, then it could be used, or it could be ignored. Or if on every page there were 2 edit buttons to choose from. One for the old editor and one for the new editor. Explain the change at the top of every page for awhile. Then it would be additive, optional, and helpful to some people. --Timeshifter 19:12, 2 August 2009 (UTC)

{{Citation needed}}.
Also, Special:Preferences.--AB 19:22, 2 August 2009 (UTC)
Thanks. I understand how to change my own personal settings, but this doesn't help unregistered users in their editing. Also, there is no way for registered users to install 2 edit buttons for every section. One for the new editor and one for the old editor. I want to choose between the editors.
In the preferences (editing tab) is this:
"Enable section editing via [edit] links"
I would like a choice:
"Enable section editing via 2 edit links - one each for the old and new editors." --Timeshifter 21:40, 2 August 2009 (UTC)
I understand there is a switch for source code editing.--AB 22:01, 2 August 2009 (UTC)
After clicking the edit link one can click the rightmost icon in the toolbar. It says "View Wikitext" when you run your cursor over it. Clicking it takes one to the wikitext source editor. --Timeshifter 09:15, 3 August 2009 (UTC)
But that gives you a wikitext "prettyfied" by the new editor, not the original wikitext. Also, what you code there will be "prettyfied" by the new editor before the page is saved. It may differ from the original wikitext and, if the new editor breaks templates, the wikitext mode will break them too. --Ciencia Al Poder (talk) -WikiDex 14:24, 3 August 2009 (UTC)

(unindent) I agree. I see the need for standardization though. But standardization to what? I think it would be a mistake to standardize away from wikipedia at this point.

I was thinking that maybe someday the new editor could just get rid of the intermediate step of wikitext altogether, and go directly to HTML. Then there would be no need for the intermediate clipboard.

But then Wikia would have to differentiate itself from blogs and who already have a visual editor and an HTML editor.

What makes Wikia different is the use of templates and the use of collaborative editing. If the new editor could somehow also edit templates, then there would be no need for wikitext at all.

I dislike the blog format of dated entries because I update pages. So the date no longer makes sense. I am new to blogs, and I will ask if the dates can be removed. If free blog sites would allow me to get rid of the dates, and would allow the use of templates (server-side include pages) then they would be more useful to me.

But the 2 big free blog sites do not allow collaborative editing as far as I know, and I need that. I want my site to continue on without me if necessary. It would be really great if Wikia could have as high a traffic rank as the 2 big free blog sites. Those sites give total control of blogs to their owners. Wikia does not do that.

So I would like to see a hybrid free hosting service that gave total control of a site to the "owner". Combined with a WYSIWYG editor, templates, and collaborative editing (controlled by the owner). And without wikitext. A visual editor with the option to edit the HTML too.

Such a dynamic, hosted website service would be very popular, and Wikia is almost there. The steps away from Wikipedia though are going to be problematic. The new editor's intermediate clipboard is the problem. So the new editor should be optional for now in my opinion. --Timeshifter 15:42, 3 August 2009 (UTC)

Thanks for the feedback: going down TimeShifter's list:
  • We understand that a portion of users come from Wikipedia: however, it would not be sensible to assume all users come from Wikipedia, or that Wikipedia should dictate everything we do. WP themselves are moving towards creating a better editor.
  • I'm not sure what the issue with templates and blogs is?
  • We want to make the new editor have as few quirks as possible - it is improving all the time, and we have plans to improve nearly every aspect of it. It's certainly not a "done" project, as it's so central to editing Wikia.
  • While moving whatlinkshere from the sidebar may be a little odd for experienced editors, don't overestimate the number of people using such links. An advanced link like that need not be in such a prominent place on an article - most users don't understand or care what it does. Certainly it's a useful and necessary page, but the belief is that it belongs with the article it refers to, not the sidebar.
  • For creating links: you can now use that and other simple wikitext in the WYSIWYG editor. However, one of main reasons for the new editor is that the idea is that doesn't require any coding knowledge for more edits. There is no intention to make users have to learn anything new, as WYSIWYG editing should be immediately recognisable from using Word, etc.
  • Regarding preferences and enabling/disabling it: overhauling user preferences and better exposing such options to users is one of the items that it working its way to the top of our list. MediaWiki itself has made some strides in that area in the most recent releases, but we're looking at doing more.
Keep the thoughts and ideas coming. We're listening! Kirkburn  talk  contr  @fandom  15:47, 3 August 2009 (UTC)
I like the goals of the new editor. But its implementation is very difficult at times. For example; try pasting a plain-text web address into this city page. Try it using the latest version of Firefox.
Click on the edit link to the right of the "Links" section at the top of the page. Try copying and pasting this plain-text link:
Note the number of steps involved. In the edit window for Google Mail it is a one-step copy and paste.
On the city page try pasting it to the right of "Link:" and a space.
The first problem is that the new editor tries to select "Link:"
This is problem number one. We are not trying to replace "Link:"
So we have to play around with spaces and the cursor in order to deselect "Link:"
I usually do this by adding two spaces and placing the cursor between the 2 spaces. I don't have this problem in the edit window for Google Mail. I do have this problem with Yahoo Mail. So it seems that Google Mail has figured out how to prevent this problem.
Then I right-click to get the context menu. I click "paste." Then the intermediate clipboard comes up. I ignore the keyboard instruction, and right-click in the clipboard form. From the context menu I click paste.
I click OK. I preview the page section. The link has been made clickable. Done. This is far more complicated and lengthy than either the old editor, or Wikipedia, the 2 major blog sites, Google Mail, Yahoo Mail, etc.. --Timeshifter 16:58, 3 August 2009 (UTC)
I can reproduce the highlighting issue with the right-click menu (which I'm going to test more and put in a ticket about), but everything else seems fine to me. Using the keyboard I can paste URLs without issue, and there is still the option of using wikitext input instead. While I realise the right-click paste/clipboard security popup is annoying, I believe we can't do anything about it at the moment - keyboard shortcut pasting works fine though.
That being said, the intended flow for adding WYSIWYG links is - place the cursor where you want the link, click the link button. Type what you need, click okay. Kirkburn  talk  contr  @fandom  14:11, 4 August 2009 (UTC)
Thanks for passing on the highlighting issue. Many users may give up at that problem point.
The popup window says: "Please paste inside the following box using the keyboard (Ctrl+V) and hit OK."
Right-clicking in the popup box, and then clicking "paste" is easier for me. It works fine. Could that info be added to the popup window too?
A suggestion for the future. I like how some editors (Microsoft Frontpage, for example) allow one to paste in a URL, and it is automatically put into clickable format the moment a space is added at the end of the URL. The link text is editable then. One can start typing in new label text. The URL remains the same.
I have another suggestion. The popup window says: "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."
This is unclear. Changing my browser settings will not allow me to access my clipboard data directly, and get rid of the popup window. Could the popup window wording be clarified? --Timeshifter 02:29, 5 August 2009 (UTC)
That is quite true, thanks for pointing it out. As far as I know, the issue is only with mouse clicks, so telling users to paste using the keyboard in that window makes no sense, as they can paste quite happily using the keyboard in the main edit window. I've modified the messages to be clearer, and not to insinuate users should fiddle with their security settings in any way.
Also, recognising links on the fly sounds like quite a good idea. Kirkburn  talk  contr  @fandom  16:38, 5 August 2009 (UTC)

Image captions: wikitext brackets showing up in visual editor

I noticed that some of the wikitext brackets are showing up in some image captions in the new visual editor. I don't think any wikitext brackets are supposed to show up in the visual editor in code form?

See: this city page

Click on the edit link for the "Top" section. Note that some of the wikitext brackets are showing up as code. Not always though. Some brackets are not showing up. For example; the caption for the bottom image. It shows up correctly with a clickable external link. No exposed wikitext brackets.

So I guess only the brackets for internal links are exposed in the visual editor.

Click the preview button at the bottom of the edit window. Then you can see the finished image captions at the top, and the edit window of the visual editor at the bottom. --Timeshifter 04:00, 5 August 2009 (UTC)

I believe it's at least partly intentional that (most) caption formatting is shown as wikitext at the moment. However, I'm not sure it's still required, plus your example is showing a bug or two. I'll have a look into it. Kirkburn  talk  contr  @fandom  16:43, 5 August 2009 (UTC)

Not removing &nbsp;

Would it be possible to convince the RTE to leave &nbsp; in the page code? With every edit it converts all &nbsp; to normal spaces. That's really anoying. --Justme2 00:25, 8 August 2009 (UTC)

I can confirm this, and I agree - &nbsp; is needed in some cases. We'll take a look. Kirkburn  talk  contr  @fandom  13:10, 11 August 2009 (UTC)
But don't add innecesary &nbsp; in the code, as it's doing now with normal spaces see first change. This makes the code more difficult to read for people that uses the MediaWiki editor. --Ciencia Al Poder (talk) -WikiDex 08:49, October 3, 2009 (UTC)
This occurs with shift+space as far as I know. It's surprisingly difficult to fix cleanly, but it's noted, and known. Kirkburn  talk  contr  @fandom  18:39, October 5, 2009 (UTC)

Link target shifting problem

I have found a problem with links. After some edits with RTE for nearly every link in the article the link target of the following link is used. The link text however stays the same. Some examples:

I think this is huge problem if such edits are not detected, because the problem is not obvious, and readers get really confused. --Justme2 00:57, 11 August 2009 (UTC)

Thanks for the report - we'll look into it. Kirkburn  talk  contr  @fandom  13:07, 11 August 2009 (UTC)

RTE adds spaces between templates

See here the last four versions until now, all done with RTE. It might be a wiki specific problem, that one got imported into Wikia from another farm. (Why is there no Special:DisableRichTextEditor?)--AB 22:25, 18 August 2009 (UTC)

Happening on w:c:fallout as well, see here for an example. -- Porter21 (talk) 07:07, 19 August 2009 (UTC)
Yes, the RTE is adding spaces in a lot of random places in a lot of articles. I'm fairly sure that Wikia is aware of the problem (it's quite obvious, would have been picked up very early on ;)), but judging from the fact that it's been a while and it's still happening, they haven't been able to fix it yet. All we can do is patiently wait and keep faith in Wikia... Wjxhuang, the 888th Avatar {Talk} 08:04, 19 August 2009 (UTC)
Oh well, I didn't know better.--AB 14:42, 19 August 2009 (UTC)
Well, we had the spacing problem for a while, then it disappeared (hence I assumed it had been fixed) and now it has re-appeared recently. -- Porter21 (talk) 15:28, 19 August 2009 (UTC)

Thanks for bringing it up. Regarding the small question of the special page: it's a temporary solution. On our list is a plan to implement a proper framework for preference enable/disable links. Kirkburn  talk  contr  @fandom  21:16, 25 August 2009 (UTC)

Please forward my thanks to whoever made useeditor=wysiwyg work.--AB 22:04, September 18, 2009 (UTC)
Any idea on when this is going to get fixed? Having to tidy up edits like this gets a bit irritating after a while... -- Porter21 (talk) 07:14, September 22, 2009 (UTC)
It's still doing it. -- Porter21 (talk) 20:30, October 20, 2009 (UTC)

HTML Break Code Change

I noticed pretty often that all my <br> linebreaks which I edited with the old, code editor get mass changed when certain users edit pages, probably with the new WYSIWYG editor.

The result is that all my <<content>><br> gets converted into <br><<content>></br>. The problem, with this is that <br></br> is a XHTML 1.1 standard (XHTML development was officially discontinued a while ago, and my wiki never used it anyways), while the standard tag <br> (without ending) is still correct, even in the recent HTML 5 specification.

Reference Site

Since several rather high-traffic pages of my wiki use a good lot of <br> tags, this can get pretty confusing and annoying, especially when old code editors conflict with newer WYSIWYG editor users. Would it be a problem to remove this function because wikia (or a connected site) possibly needs XHTML data?

Crynsos Talk 01:39, 25 August 2009 (UTC)
That certainly shouldn't be happening! Do you have any specific examples of this occurring? It may be important to know which browser the user is using when it occurs.
I've not been able to reproduce it on Firefox 3.5 or IE8. Kirkburn  talk  contr  @fandom  21:22, 25 August 2009 (UTC)
Seemingly the editor updates worsened the problem since I last saw it in the editing difference logs. I also remembered it a bit wrong, the editor does not close <br> tags but instead replaces them with <br />, still unwanted XHTML though.
Also, I usually try to preserve both a good resulting page layout AND keep the wikicode more or less organized, so even advanced editors or myself can find specific code parts with ease. When pages were edited with an older version of the new editor, it jumbled this in-code layout up a bit, but when I was just testing editing a page with the new editor again (in Firefox 3.5), it re-arranged various pieces of code (especially at the start of the table code) and made the code pretty much unreadable for any human being.
Comparison picture of how the code should look, of how it looked after editing with a previous new editor version and how it looks after editing it with the current new editor version: Comparison
Also, here is the difference page between the old and new code layout, I did nothing but add a bit of Test Text to the lower end of the page: Difference Page

Would marking pages with the (somewhere above mentioned) <NOWYSIWYG> possibly help in this case? I just hope I don't bother you guys too much with such rather complex requests.
Another XHTML vs HTML Resource Link
Crynsos Talk 16:44, 29 August 2009 (UTC)

I'm not sure I would class conversion to <br/> as a bug exactly, but I'm generally for keeping code as unchanged as possible - and this applies with tables too. Unfortunately, however, due to how the editor works, this is not particularly easy. Still, it's on our list to improve, and I absolutely understand having tables change radically is a pain. The __NOWYSIWYG__ is indeed you main recourse for this issue at the moment. Kirkburn  talk  contr  @fandom  18:29, 31 August 2009 (UTC)

Yeah I guess I wouldn't exactly count it as a bug myself either, just as rather unnecessary code transformation because it should be all correct and updated when looking at the current HTML standards. It's more a "Don't fix if it's not broken-case", combined with the unintentional screwing up of the in-code format. Guess that's just because machines decide quite different than the average human.
The few pages which use this special code are important, but only get edited by advanced editors anyways, so I guess it shouldn't bother anyone that we use the __NOWYSIWYG__ markup. Don't concentrate too much on this problem, I just hope more important problems (if any) with the new editor get fixed. This case is quite done for me, thanks for the comments.
Crynsos Talk 17:51, September 2, 2009 (UTC)
Please have a look at the rendered page source at the very top: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
Websites rendered with MediaWiki software apply to XHTML 1.0 Transitional - so: <br> is wrong, <br /> is correct. -- [ defchris ] · [ Diskussion ] · 16:52, September 3, 2009 (UTC)
Ah, didn't really think about looking at that... but anyways, XHTML development was stopped (at least the W3C's work on it, I don't know if anyone else decided to continue yet), at least for a while. So unless the MediaWiki software heavily relies on XHTML, it should be probably removed, once there's a reasonable amount of time left for the programmers, aside from the other projects...
And even IF MediaWiki still had to rely on XHTML it should probably upgrade to XHTML 1.1 (the last update so far)
Crynsos Talk 10:49, September 5, 2009 (UTC)

The ugly bug returns? :( ~Joey~ ^Talk^ 01:42, September 5, 2009 (UTC)

If you mean the masses of extra code: unfortunately I have no idea where it could have come from - it's possible it was a mistaken or invalid paste from the user.
If you mean the table expansion: this is something we don't like either, but is very hard to change. Kirkburn  talk  contr  @fandom  12:39, September 14, 2009 (UTC)
The extraneous script block is a conundrum.
If by "table expansion" you mean the style of presenting wiki markup code as one cell value (and it's optional style) per line instead of one complete row of cell values per line then for what it's worth I find that format much easier to work with even though I exclusively use the plain text editor and therefore see it for even the simplest of tables. I remember thinking it was wasteful of (editor) screen space in the early days but as the tables I worked on became increasingly complex the benefits of one cell (style + value) per line quickly became apparent. --najevi 22:16, September 18, 2009 (UTC)

Order of table attributes swaps with each edit

By using the RTE constantly the order of the table attributes is swapping. This really obfuscates the diff pages between two following versions of an article. Real changes are very hard to detect because of this. If you are looking for vandalism just because of this behavior you have to do a very extensive search to find out what has been changed on a page and if this was the only thing. Below there are two examples for lines which always swap from one version to the other in one edit, and back in the next edit.

Example for table start:

  • {|style="text-align: center;" class="DB_blue_table"
  • {|class="DB_blue_table" style="text-align: center;"

Example for table cell:

  • |style="text-align: left;" colspan="9"|Some text.
  • |colspan="9" style="text-align: left;"|Some text.

Example edits (diff): [3] [4] [5] [6] (Complete diff over these four edits)

It would really help monitoring pages with such tables, if the stupid editor would not blow up the diff all the time. --Justme2 15:28, October 1, 2009 (UTC)

Oh, wow, that's very odd. Thanks for the report! Kirkburn  talk  contr  @fandom  15:15, October 2, 2009 (UTC)
This should now be fixed. Kirkburn  talk  contr  @fandom  15:05, October 15, 2009 (UTC)

__NOWYSIWYG__ doesn't work in transclusions

If you place __NOWYSIWYG__ inside a template, and you put that template in any article, the article should use the MediaWiki editor, not the new editor. But this doesn't work! Only works when the __NOWYSIWYG__ is placed in the article itself. This mean that you can't tag several pages that use a specific template to use the MediaWiki editor. Also, in wikis where the RTE was enabled recently, I wanted to use __NOWYSIWYG__ inside a template so we can track where is used so if we decide to disable RTE in our wiki we could track the pages that have it so it could be removed (because when not enabled, the magic word is shown as is in the page) --Ciencia Al Poder (talk) -WikiDex 08:45, October 3, 2009 (UTC)

Tested, and you're correct. NOTOC works through a template, but NOWYSIWYG doesn't - we'll take a look. Kirkburn  talk  contr  @fandom  18:37, October 5, 2009 (UTC)
This should now be fixed. Kirkburn  talk  contr  @fandom  15:06, October 15, 2009 (UTC)

Editor code upgrade coming soon

Just a quick note to let you know, we're working on upgrading the core editor code to the latest release of CKEditor (3.0). It should result in a much faster editor - we know speed is one of the main issues at the moment :) It's a fairly sizeable project, so expect it in a couple of weeks. I'll keep you updated. Kirkburn  talk  contr  @fandom  15:13, October 15, 2009 (UTC)

Update: the overhaul is progressing well. We believe we've eliminated many of the known bugs, especially related to spacing. At the moment we're working on getting it finished as soon as possible, for everyone to benefit! Kirkburn  talk  contr  @fandom  01:26, November 13, 2009 (UTC)

Will this editor be available to the Wikimedia Foundation?

Is this editor open source? And if it's not, will you make it available to the Wikimedia Foundation if the community or the foundation decides to implement a WYSIWYG editor on Wikipedia? -- 21:03, October 16, 2009 (UTC)

Template/RTE bug

Whenever you edit a page with w:c:fallout:Template:ID (e.g. w:c:fallout:Fallout 3 armor and clothing), the RTE displays the latter half of the template code plus a bit of gibberish behind it. When saving, the template and its contents are removed from the page and replaced with the aforementioned output. Not sure what is causing this; the RTE has no problem with w:c:fallout:Template:DLC ID which differs only in what's inserted at the beginning of the string.

Example diffs here and here. -- Porter21 (talk) 15:48, October 25, 2009 (UTC)

RTE adds unwanted lines between tables and headlines which affect the layout

It seems that RTE still likes to add additional unwanted empty lines between a table followed by a headline. However it doesn't do it if there is normal text after the table. Here are some example RTE null edits. Have a look at the last changed row in the the first examples and at the first changed row in the third one: dif1, dif2, dif3

Also I'm not sure what's happening to those scope-lines in the tables. --Justme2 10:07, November 5, 2009 (UTC)

Accidental Spaces at the beginning of lines.

At BioShock Wiki the rich text editor is causing formatting problems for new users. People who use Rich Text Editor keep accidentally adding spaces at the beginning of lines, probably thinking that this will indent the text, but instead causing the page format to behave like a <pre> tag had been used. For example: Formatting Disaster and This is Awful.

This is annoying when it covers an entire page.

Of course, people using the regular edit method might also add accidental spaces, but the troubling thing is that for all of these users I talked to, they each said that the broken format did not show on the page when they previewed it in the Rich Text Editor. None of them saw the broken formatting until I pointed it out to them and they went back to check at a later date.

This is such a common issue that Rich Text Editor is actually hurting these new users, and the wiki, more than it helps. --Gardimuer 01:03, November 9, 2009 (UTC)

Nested templates





Is changed into:

|1 = <nowiki>{{about
|2 = one}}</nowiki>
|3 = two

|1 = {{about
|2 = one}}
|3 = two

|location = <nowiki>{{MapLink

|location = {{MapLink

--Kaseijin 13:38, November 13, 2009 (UTC)