Jump to navigation Jump to search

About this board

Previous discussion was archived at Talk:VisualEditor/Archive 1 on 2015-09-01.

VisualEditor Stuck: Cannot read property 'toText' of null

Fatihbahceci (talkcontribs)

Here is code which stucked


var element,target=title.toText(),


Here is console error

load.php?debug=false…ersion=1c9irsr:1892 Uncaught TypeError: Cannot read property 'toText' of null at (load.php?debug=false…ersion=1c9irsr:1892) at (load.php?debug=false…ersion=1c9irsr:1893) at (load.php?debug=false…ersion=1c9irsr:1734) at (load.php?debug=false…ersion=1c9irsr:1890) at (load.php?debug=false…version=1c9irsr:965) at (load.php?debug=false…version=1c9irsr:971) at (load.php?debug=false…version=1c9irsr:974) at (load.php?debug=false…version=1c9irsr:974) at (load.php?debug=false…version=1c9irsr:974) at (load.php?debug=false…version=1c9irsr:974) @ load.php?debug=false…ersion=1c9irsr:1892 @ load.php?debug=false…ersion=1c9irsr:1893
ve.ui.MWLinkAction.static.getLinkAnnotation @ load.php?debug=false…ersion=1c9irsr:1734 @ load.php?debug=false…ersion=1c9irsr:1890

Reply to "VisualEditor Stuck: Cannot read property 'toText' of null"
Marlonke (talkcontribs)

I've followed the instructions as posted on VisualEditor/Skin requirement both the current version and the ones in the history tab. After adding the three div's with their IDs to my skin, the problem persists; nothing happens when I either call the page with the ?veaction=edit parameter, or when I create a button doing essentially the same. The only clue I have is the class 've-not-available' being added to the page after it's loaded.

The VisualEditor works fine on the stock skins I have: Vector and Chameleon.

I'm using the following versions:

VisualEditor 0.1.0 (9da5996) 16 aug 2016 15:40

MediaWiki 1.27.1 (a52d35d)

My HTML structure looks as followed (note the added mw-content-text and content divs)

<div class="grid-x  grid-margin-x">

               <div id="content">

                   <div class="cell">

                       <div  class="contentbody" >

                           <div id="mw-content-text">


                           if( !$this->atHome) {

                               // do not display the HTML tag if the header is empty

                                   if ( $this->skinData->data['title'] != '' ) {

                                       echo '<h1 id="emmskin-pageheader" class="page-title">';

                                       $this->skinData->html( 'title' );

                                       echo '</h1>';



                               //output the post-processed bodytext

                               echo $this->bodyTextHTML;







I've tried the following:

- Followed the instructions from the history pages of the Skin Requirements page, in which different names are used for the required divs

- Looking in the support section for someone with a similar problem

- Using the Vector/Chameleon skin HTML structure as inspiration, and trying to make everything in my skin look as close as possible.

I'm guessing this issue has something to do with either faulty configuration, or something lacking in my skin. I've found no clear way of debugging this so everything else I tried is largely trial-and-error to no avail.

Marlonke (talkcontribs)

It was indeed faulty configuration. Through debugging (breaklining some of the VE scripts) I managed to find out that the custom skin wasn't seen by VE as a 'supported skin'. I remedied this by adding '$wgVisualEditorSupportedSkins ['mySkin'];' to LocalSettings.php

Reply to "VE doesn't load on custom skin"
Hoefsldyla (talkcontribs)

Is there any way to stop VisualEditor from automatically adding the <nowiki> tags. For example if I want to type <div> Something </div> it changes it to <nowiki><div></nowiki>Something <nowiki></div></nowiki>

Jdforrester (WMF) (talkcontribs)

No. VisualEditor is a visual editor and is not appropriate for manually inserting raw HTML. For that, use the wikitext editing mode.

Reply to "Stop VE adding <nowiki> tags" (talkcontribs)

Hi, we have one very huge Page in one of our customers mediawiki. Editing this page will cause an alert windows after about 30 seconds witch says: "http". Not more. The Parsoid log says: ...started parsing... and then ...completed parsing in 37661 ms... so im guessing on a timeout problem. All other Pages load fast and fine. Is there a way to increase timeout? Thank you for every help and hint :-)

Ti infotrad (talkcontribs)
Reply to "Timeout in VisualEditor"

Is there anyway to make the "Add Templates" feature use "subst:"?

Summary by
Hoefsldyla (talkcontribs)

I am aware you can use `subst:Template` when searching and it will substitute. My problem is that I want TemplateData to still be able to function.

Hoefsldyla (talkcontribs)

To try get around this i created a template called "Template:Subst:TemplateName" which should work however the Template inserter upon clicking "Insert" just loads forever and never insert anything and you are not able to cancel

Reply to "Is there anyway to make the "Add Templates" feature use "subst:"?"

Enabling VE in Category Page? And enable VE always.

AmazingTrans (talkcontribs)

I'm wondering

  1. when i go to a category page, how can i enable visualeditor in that page?
  2. when i search for a page that doesn't exist, Create the page "Test" on this wiki! See also the search results found. By clicking the Test word, it always automatically select Create Source. Is there anyway I can have it select Visual Editor first?
AmazingTrans (talkcontribs)

I have tried the following, and the category doesn't seem to have VE Edit available, only sourceedit. I notice the NS_USER is not necessary, somehow VE is always shown there.

$wgVisualEditorNamespaces[] = array_merge($wgContentNamespaces,array( NS_USER, NS_CATEGORY));

I also tried this, and it didn't work.

$wgVisualEditorNamespaces[] = NS_CATEGORY;
Elitre (WMF) (talkcontribs)
AmazingTrans (talkcontribs)

VE is already working in Main namespace. Just not working in Talk, and Category namespace.

This is on my private wiki.

Whatamidoing (WMF) (talkcontribs)

I believe that the single edit tab feature will solve #2. (talkcontribs)

Since I've updated to MediaWiki 1.26.2 and the latest VisualEditor I also cannot enable VisualEditor for category pages. Before the Update (1.25.3) I could edit category pages. (talkcontribs)

I have the same issue. I would like to enable VisualEditor for Category pages. Also running 1.26.2.

Has anyone managed to enable this yet? (talkcontribs)

Add this to your LocalSettings.php

// Enable VisualEditor in Category Page

$wgVisualEditorAvailableNamespaces = array(


); (talkcontribs)

It can easily be done if you are using custom fields like pods etc. Just extend the current category and add visual editor as field

Reply to "Enabling VE in Category Page? And enable VE always."

VE has problems with editing <ref name="XYZ" /> link

Der Keks (talkcontribs)
Der Keks (talkcontribs)
Reply to "VE has problems with editing <ref name="XYZ" /> link"

Visual Editor does not seem to be compatible with drag and drop or copy and pasting images?

Thedonquixotic (talkcontribs)
Reply to "Visual Editor does not seem to be compatible with drag and drop or copy and pasting images?"

mediawiki.notification API z-index issue?

Revansx (talkcontribs)

Hi, I have a bit of javascript that I run in Common.js that uses the command "mw.loader.load( ['mediawiki.notification', 'mediawiki.api'] );" on any page open for edit to define a standard mediawiki pop-up notification. It is immaterial, to the question but the purpose of the pop-up notification is to alert the (enterprise SSO immutable session) user that their session may be expiring and to save their work..

The script works great for action=edit, and action=formedit urls, but with veaction=edit urls the pop-up notification window is "behind" the VE editor elements such that the user can not interact with it.

The script is benign and effortless to test.

I am running:

  • MW:1.30 and
  • VisualEditor: 0.1.0 (61f161a) 14:07, 2 October 2017

The link to my javascript is:

As you can see, I set the z-index value to an extremely large value so I have ruled out the easiest of fixes.

Can someone take a peek at this and help me identify if the problem is a deficiency in the javascript, or if it is an issue with the way VE elements are stacked.

Thank you in advance.

- User:revansx (Rich)

Matma Rex (talkcontribs)

I don't see this problem on my local testing wiki (using latest Git master of MW and VE, 1.32-alpha).

I ran your script and the notification displays on top of everything: after scrolling down, it repositions itself, but stays on top of the editing toolbar: In both cases the links in the notification are clickable.

It is possible that the earlier versions you're using had some issue that caused this to not display correctly. I couldn't easily find the patch which might have fixed it, though :/

Revansx (talkcontribs)

hmm.. thank you for looking at this. I'm glad it worked for you. I'm not in a position where I could simply upgrade and see if that solves the problem. I'm really hoping to figure this out for my current setup. I'm currently inspecting and tinkering with elements in the developers console hoping to figure out what is on top of what.

MarkAHershberger (talkcontribs)

Note that I've tried this using my user js on a 1.27 wiki and couldn't reproduce @Revansx's problem.

Revansx (talkcontribs)

Workaround/Fix - From the browser developers tools, I found that the problem is related to the CSS parameters "pointer-events:none; opacity:0.5;" appplied to the element .ve-loading #content > :not( .ve-init-mw-desktopArticleTarget-loading-overlay ), .ve-activated .ve-init-mw-desktopArticleTarget-uneditableContent

I was able to functionally solve the problem by adding #mw-notification-area { pointer-events:initial; opacity:1.0; } into Mediawiki.css.

Clearly this is not a correct solution to the root cause. If anyone can imagine why the notification is being styled this way, please let me know. thanks!

Revansx (talkcontribs)
Reply to "mediawiki.notification API z-index issue?"

Can you remove tools/gadgets from the toolbar?

JoshHarry (talkcontribs)

My wiki doesn't require all of the tools/gadgets in the default Visual Editor toolbar, is there a way I can the remove tools that are not needed?

Whatamidoing (WMF) (talkcontribs)

Which tools do you want to remove?

I think that some of them automatically disappear if not installed on the local wiki (cite.php, maps, heirolyphics, etc.).

JoshHarry (talkcontribs)

Thanks for the reply

Here is a list of the tools I (probably) want to remove:

From the Format Paragraph tab: Sub-headings 3 and 4, Preformatted, Block Quote and Page Title

From Structure: the increase and decrease indentation opitions

From Insert: Comment, Hieroglyphs, Musical Notation, Signatures, Gallery, Chem Formula, Math Formula, Map, Code Block, Graph, Ref List

From Style Text: basically all apart from Bold and Italics

and the Cite tab (but you already mentioned that won't appear if not installed)

Whatamidoing (WMF) (talkcontribs)

I think – but note that I'm neither omnsicient nor a dev – that Hieroglyphs, Musical Notation, Chem Formula, Math Formula, Map, and Graph (and the ref items) will automagically fail to appear. I think that those are all controlled by extensions and that they're meant to "fail gracefully".

That leaves Comment, Signatures, Gallery, Code Block, and the character stylings that will probably need direct intervention. I'd encourage you to keep the "Language" item in the character stylings menu; otherwise, if anyone ever posts an Arabic or Hebrew character, it could get a bit messy.

I'll ask around and see if I can find out more about how to do this. @Deskana (WMF) and I were talking about adding an item the other day; maybe he will have some ideas about how to remove one.

Deskana (WMF) (talkcontribs)

Almost anything is possible in code, so yes, it would be technically possible for you to do this. That said, you'd have to change the JavaScript code in VisualEditor yourself, and given that it's not designed for menu items to be swapped in and out arbitrarily, it probably won't be very easy for you to do so.

Reply to "Can you remove tools/gadgets from the toolbar?"