Forum:New Visual Editor: Problems and Suggestions

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


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

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

General 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)

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. 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 some advanced wikitext?
Let's say we put things like in the page:

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

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 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 http://images.wikia.com/common/releases_trunk/skins/common/images/button_link.png (no dialog mode) Fixed
 * 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 Fixed
 * 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.

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)

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)

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

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)

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)


 * 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:
 * 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)

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? 71.237.104.238 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 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)

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: –    |   []            undefined   undefined     ==

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


 * I can confirm this, and I agree -  is needed in some cases. We'll take a look.  13:10, 11 August 2009 (UTC)


 * But don't add innecesary  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. 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:
 * http://danball.wikia.com/index.php?title=Irritation_Stickman&diff=next&oldid=23342
 * http://danball.wikia.com/index.php?title=Powder_Game&curid=1911&diff=23434&oldid=23341
 * http://danball.wikia.com/index.php?title=Powder_Game&diff=23446&oldid=23443

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

HTML Break Code Change
I noticed pretty often that all my  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 < > gets converted into  < >. The problem, with this is that   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   (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  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. 21:22, 25 August 2009 (UTC)

, still unwanted XHTML though.
 * 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  tags but instead replaces them with


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

 is correct. -- [ defchris ] · [ Diskussion ] · 16:52, September 3, 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" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 
 * Websites rendered with MediaWiki software apply to XHTML 1.0 Transitional - so:    is wrong, 


 * 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?
http://monsterhunter.wikia.com/index.php?title=Game_List&diff=prev&oldid=65468 :( ~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. 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: Example for table cell:

Example edits (diff):    (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! 15:15, October 2, 2009 (UTC)


 * This should now be fixed. 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. 18:37, October 5, 2009 (UTC)


 * This should now be fixed. 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. 15:13, October 15, 2009 (UTC)