Disabling the VisualEditor[]
The VisualEditor formats template code contrary to legibility and established convention and often encourages very poor formatting (leaving colored HTML (span style="font:Arial:; line-height:1em; color:yellow" and all that shit), etc.), is there a way to disble it? I am aware that Wikia wants anons to edit easier and wants people to "have a better experience editing without seeing code" but it creates a many headaches for people who believe in true wiki editing (coding). The template coding inconsistency is especially a problem; I don't want to see every darned parameter on one monolithic line. Alamko7 (talk) 03:22, July 29, 2015 (UTC)
- Can send in specific examples of the bad formatting to Special:Contact/bug? We'll want to look into this in more depth there. Besides that, we recognise the single-line approach for templates is not ideal - it's something that's on our list to change in the future. Kirkburn talk contr 14:52, July 29, 2015 (UTC)
- I would say that the HTML is not entirely the fault of VisualEditor (perhaps bad formatting is the wrong word... overzealous prservation of formatting?) but rather the fault belongs to unaware users who think it is fine to copy and paste from Word and VisualEditor's WYSIWIG abilities (it is such a pain to clean up those rampant "mso-font-family-ja-ar-en-etc: Arial Meiryo Tahoma" rubbish! WYSIWIG has its upsides and downsides... Occasionally an anon even somehow manages to copy-and-paste a template instead of using it the right way resuting in an expanded template HTML code in an article...) Meanwhile, the template formatting is a problem that would be most easily solved by providing the option to disable VisualEditor. I understand that fixing this is in the pipeline but VisualEditor is the sole source of these headaches and disabling it in the meantime would do wonders for readibility and ease of editing. Alamko7 (talk) 04:49, July 30, 2015 (UTC)
- We have strong evidence that the VE has pretty positive effects on editing overall, so it's not something we'd like to do without strong evidence of problems. This is something we can investigate in more depth via Special:Contact, however :) Kirkburn talk contr 14:56, July 30, 2015 (UTC)
- I would say that the HTML is not entirely the fault of VisualEditor (perhaps bad formatting is the wrong word... overzealous prservation of formatting?) but rather the fault belongs to unaware users who think it is fine to copy and paste from Word and VisualEditor's WYSIWIG abilities (it is such a pain to clean up those rampant "mso-font-family-ja-ar-en-etc: Arial Meiryo Tahoma" rubbish! WYSIWIG has its upsides and downsides... Occasionally an anon even somehow manages to copy-and-paste a template instead of using it the right way resuting in an expanded template HTML code in an article...) Meanwhile, the template formatting is a problem that would be most easily solved by providing the option to disable VisualEditor. I understand that fixing this is in the pipeline but VisualEditor is the sole source of these headaches and disabling it in the meantime would do wonders for readibility and ease of editing. Alamko7 (talk) 04:49, July 30, 2015 (UTC)
Bug[]
I hope someone's watching this page, I'm not seeing a bug report form specifically for VisualEditor.
Anyway, in case this isn't already known, VisualEditor messes up parsing when there are tags of the "include" family placed inside templates holding table components.
On my wiki specifically, the code looked like:
{{Unitlist start|ability=yes}} // This is the table header
<onlyinclude>{{Unitlist item
|classevol = yes |awaken = ... // This is the information pertaining to the
// subject. Actual content is just stats and such.
...}}</onlyinclude>
{{Unitlist end}} // Table closer - just "|}", actually
This ends up rendering both a template and a "literal" table. The table is exactly what the template should look like, and you can edit by double-clicking on the cells, but it's entirely separate from the actual template and won't interact with it. Meanwhile, the actual template is invisible (just a single spacebar of whitespace), placed above the table that came from nowhere, and it's really easy to miss if you don't look carefully.
(I'll upload a screenshot if anyone wants it, I didn't want to upload right away in case there was some kind of rule against that.)
It looks like the glitch still happens when the <onlyinclude> is changed to <noinclude> or <includeonly>. My quick tests with the header/closer and the content inside the tags weren't very conclusive of effects, so I'm not sure if they do contribute to the bug as well.
-Illumini9 (talk) 10:53, September 30, 2015 (UTC)
- All bugs should be reported via Special:Contact/bug - could you send this it to there (with links to test examples, if possible), please? Thanks! Kirkburn talk contr 11:48, September 30, 2015 (UTC)
To disable VisualEditor[]
Is there any way possible to disable the VisualEditor on a wiki? Kisses Audrey 23:01, March 28, 2016 (UTC)
- Wiki-wide, no. That would violate the Terms of Use. However, you could remove it via personal scripts.
Joey (talk)
I too, am having a very much hate and no love relationship with the visual editor[]
It got to the point that, while trying to create a blog post for my wiki (apparently it is not possible to use the Source Editor with blog post creation. I think that might be a separate bug), I got fed up with it and decided to save and switch to source editing even though the post wasn't complete. Like perhaps I should've done from the start, but I didn't think it was possible for a WYSIWYG editor to mess up something as simple as bullet points (underlying wikitext: "*" at the beginning of the line). Boy was I wrong!. Cases in point:
1. some of the "visual" changes got stuck and could not be removed from the editor by any means. Any attempt to do so resulted in the text insertion cursor "skipping" the unwanted text and backspacing/deleting the text before/after it (depending on which removal direction was used), or in at least one case, nothing happening at all. It was like the unwanted text was not indexed by the editor's text buffer at all, or was orphaned? I joked in the file name of one of the screenshots I took (omitted for brevity, but rest assured I will be including them at some point) that "get in touch with me" would be the last thing left in Fandom's database before its inevitable destruction.
- this may have been caused by a bug where the "list" feature of the editor toolbar would not deselect properly, but I can't be certain.
2. this is giving a whole new meaning to bullet hell (screenshots omitted). I felt like I was playing Atari's Millipede with the editor! And not in the good way.
- in the first sub case, I had extreme difficulty getting the indentation and line spacing to be what I wanted. If I split one bulleted line
3. inconsistent behavior when combining/splitting lines. Unfortunately I don't have any screenshots because I couldn't figure out what I did to cause it.
While I'm at it will listing all of my grievances with the new editors... is it just me or the source editor's preview feature, as used while I was composing this, highly inaccurate? Somehow I don't think the wiki software is going to do something as simple as replacing every beginning-of-line "*" with a bullet point + tab (Rather, multiple asterisks means indenting a single bullet). --Twisted Code a.k.a. Macks2010 (Wall) 05:45, 18 December 2021 (UTC)
- "Somehow I don't think the wiki software..." Well, looks like I was wrong. Am I just dumb and trying to indent the bullet points above the wrong way, or is this site supposed to be consistent with MediaWiki-style bullet points (As I originally assumed), and I've stumbled across a yet another bug?--Twisted Code a.k.a. Macks2010 (Wall) 05:54, 18 December 2021 (UTC)