Jump to navigation Jump to search

About this board

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

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?"
Virgobowl (talkcontribs)

Where can I find documentation for modifying the toolbar in a standalone installation of the VisualEditor? Specifically I'd like to add new styling/formatting options

Whatamidoing (WMF) (talkcontribs)
Reply to "Modifying toolbar"

Parsoid/RESTbase working for Main Page but 404ing for sub-pages

Arshiya1234 (talkcontribs)

@Christian 1234567 @Williams

thanks in advance

i have installed visual editor 1.30 with restbase ,parsoid and nodejs and visual editor is working fine for first page

for example: Mediawiki/index.php/Main_Page -working

but it is failing 404 for subpages

for example: Mediawiki/index.php/Main_Page/subpage -failing

Reply to "Parsoid/RESTbase working for Main Page but 404ing for sub-pages" (talkcontribs)

I installed mediawiki 1.30 with visuael editor. The editor starts, edit works: I can add text.

But when I choose "Insert -> Media" nothing happens. The same when I click on the "link" Button or when I choose "bold" for a selected text - there is just no reaction.

Can anyone give me a hint on how to fix this problem?

Whatamidoing (WMF) (talkcontribs)
2003:C0:BBD9:CB00:FE70:9E8:9183:F663 (talkcontribs)

Thank you. I try it there.

Reply to "Insert Media (and other) doesn't work"

Force Line Breaks in VE

Summary by Whatamidoing (WMF)
Konjurer (talkcontribs)

Is there a way to force line breaks in the VE? The editor does not place any space after a bulleted list and it does not look very good.

ESanders (WMF) (talkcontribs)

No, empty linebreaks will be removed by Parsoid no matter where they are in the document. Line spacing should be the responsibility of the skin's CSS, not the user.

Reply to "Force Line Breaks in VE"

VisualEditor Error: Could not connect to the server

2 (talkcontribs)

I've just installed MediaWiki 1.30 on Ubuntu 16.04 32-bit, and I've successfully installed Parsoid and RESTbase. The 8000 port for Parsoid and 7231 port for RESTbase are all accessible and can return the correct pages. But when I try to edit or create pages using Visual Editor, the message shows up: Error loading data from server: Could not connect to the server. I've read through the docs in MediaWiki and googled my problem, but it seems that no one has met this problem before.

Do anyone know how to solve this problem? Thanks for your help.

ESanders (WMF) (talkcontribs)

You need to make sure the VE can talk to RESTbase by setting $wgVirtualRestConfig['modules']['parsoid'] in LocalSettings.php (see here), and also that RESTbase can talk to Parsoid using config.yaml (although it sounds like that is working if you can access pages on port 7231).

Reply to "VisualEditor Error: Could not connect to the server" (talkcontribs)

Hi all,

When I open Media settings (Insert -> Media) and type in "L" it says nothing found. If I type in "L3" it shows the correct PDF file. Is there a way to convince the wiki to list all the media starting with letter [a-z] or show all the available media? Because not every user knows exactly what he has to search for.

If I test with other Picture Database ($wgUseInstantCommons = true;) it works with only typing in one letter.

MediaWiki Version: 1.28.0

Whatamidoing (WMF) (talkcontribs)

Well, that works on this wiki (after a delay). What happens in the regular Special:Search box, if you type in File:L? Does it list the files that you expect?

Lanthanis (talkcontribs)

If you are not using CirrusSearch or another fulltext search engine, you have to use search parameter like "L3" or ~L (talkcontribs)

Hello i have same problem but even worse- images found only whet full file name is typed, otherwise it prints "No results found."

When search through regular search with "File:" prefix everything works good after first typed letter.

MediaWiki 1.31.0-alpha (44e0eec)

VisualEditor 0.1.0 (b82c769) 04:43, 22 января 2018


Lanthanis (talkcontribs)

Try to use wildcards like M*. That may helps.

Reply to "Media settings search is incomplete"

Unable to stop the editor from loading while offline

Summary last edited by Kaartic 04:06, 2 January 2018 8 months ago
Kaartic (talkcontribs)

Once when I loaded a page while I'm online an went offline to read the page, I accidentally hit the 'Edit' button. This started the progress bar for the editor and obviously it got stuck after sometime as it was unable to connect to the network. It was frustrating for me as I couldn't cancel the page load and thus couldn't read the article that I loaded until I got the error dialog.

It would be nice if there was a way to stop the editor from loading while it's being loaded. This would help the readers to proceed with what they were reading quickly when they accidentally hit the 'Edit' button instead of waiting for the editor to load and then cancel the edit operation.

Note: This a copy of a similar topic at the Visual Wikitext editor.

Elitre (WMF) (talkcontribs)

Isn't "Back" (or its equivalent on mobile) that button? Doesn't the requested article stay in cache, so you don't need to reconnect to read it?

Kaartic (talkcontribs)

I'm not sure what you mean by a "Back" button but I don't see any while the visual editor is loading. Here's a screen shot,

Screen shot of visual editor; loading

In case you are referring to the browser's back button, it had no effect on the loading of the visual editor (possibly due to the caching!). IOW, hitting the "Back" button on the browser and hitting "Forward" button didn't cancel the loading of the visual editor. (talkcontribs)

If you're online pressing ESC (or the equivalent in your operating system /platform) will cancel the loading. If you're offline, allowing it to pseudo-load, then pressing retry and then ESC multiple times seems to also cancel the loading.

Also this isn't specific to visualeditor. All other editors behave in a similar fashion, in fact they show the offline message even faster. One problem is that VisualEditor re-uses the same page, so after it loads if one tries to go back, they hit the same "page" or editor again.

Detecting offline mode is a very tricky thing. There might be temporary network lapses or someone might be using a local proxy that contains a cache of the page, or one of a million other possibilities when it comes to networks.

Chrome had (or has?) to have a more aggressive caching configuration option that could be activated and would store such older pages. Generally speaking though, if one wants to see stuff offline, then saving the page is the best option, even if offline it can retrieve it from the cache and create a copy.

Why isn't the VE running on talk pages anywhere?

Summary last edited by Sänger 21:00, 13 July 2016 2 years ago

There won't be any real answer at any time.

Sänger (talkcontribs)

Instead of the normal editing possibilities, on talk pages we are restricted to either only use the wikitext editor, or to this Flow environment, with its massive restrictions on next to everything. Why is the VE not enabled anywhere on talk pages?

Jdforrester (WMF) (talkcontribs)

Hi there. This question comes up a bunch, and has been answered at length a few times before, but I can't find any of those right now, sorry.

The short answer is that VE is a content editor, and is designed to make writing (long-form) content. In dozens of ways, we've optimised it around writing articles for Wikipedia, Wikivoyage and other wikis. The use cases of a semi-free-form-but-with-odd-rules discussion box are fundamentally incompatible. Providing VE for talk pages would mean making massive compromises both on being a good content editor and on being a good discussion editor. It's an anti-pattern, and it's not going to happen.

I know you have a personal animus with Flow, and that's unfortunate, but it's the option available if you think talk pages don't work well (with which I would agree).

Sänger (talkcontribs)

It's just about an editor, the difference between a plain text editor and a wysiwyg editor. There shouldn't be any big difference between editing a text on either the front or the back side of any page. A talk page is as well nothing much different to any other content page, only the content is a bit different.

It's like the difference between old fashioned WordPerfect and the wysiwyg version of the same program. Some prefer the classic mode, some the ve, but the resulting page is just the same.

Sänger (talkcontribs)

Why was this definitely not solved question closed? Your answer was just a straw man, not a real one. It's everything but closed.

Jdforrester (WMF) (talkcontribs)

Sorry, I didn't see a question in your response, just implicit accusations of bad faith and incompetence. :-) If you could re-write one that'd be great, otherwise there's nothing more to say.

Sänger (talkcontribs)

Why isn't the VE running on talk pages?

VE is a text editor, and thus should be fully capable of editing on any page, at least simple talk pages.

Jdforrester (WMF) (talkcontribs)
VE is a text editor,

As I explained, this is not true.

Sänger (talkcontribs)

To just quote the first sentence from the other side:
The VisualEditor project aims to create a reliable rich-text editor for MediaWiki.
So why do I have the impression, that either the other side is plain wrong or your "argument" is just a straw man?

Whatamidoing (WMF) (talkcontribs)

The visual editor cannot (abuse HTML definition list formatting to) fake the indentation of paragraphs. Therefore, you are likely to find using it in a talk-page discussion to be frustrating at this time.

Sänger (talkcontribs)

...yet. An editor that's capable of editing tables, using templates, setting references etc.pp. is incapable of abusing colons for indentation? Should I really believe this?

Why do I think of a nice idea to push the software pet project that's not as much liked by the community as by the WMFers?

Whatamidoing (WMF) (talkcontribs)

I think you may have to wait until phab:T6521 is resolved.

BTW, there are a few wikis that have the visual editor enabled in the Project: namespace, and which also have some discussions in that namespace (e.g., ), and we hear complaints about problems on those pages. I don't think that it would be a good idea to expand the use of the visual editor on such pages at this time.

Sänger (talkcontribs)

You insist without any real merit, that a wikipage is not the same as a wikipage. In principle all wikipages behave in absolutely the same manner, they were edited with exactly the same editor up to some time ago, when you a) tried to get so-called structured discussions, first with Liquid Threads, something that failed, now with a bit different layout system Flow, something that as well is stuck in limbo. But if you discount these, the article page uses the same syntax as the talk page, the user page uses exactly the same syntax as the talk page, with one of two available editors the can be edited in exactly the same way as everything else in the wikiverse. With the other one, the VE, you claim that these exactly same pages are magically somehow different, and one of them can't be edited in a wysiwyg-way.

BTW: Using colons to indent, instead of some software hack created by those many devs paid by content creators and talk page users, is frustrating as well, but you choose to ignore this for quite some time and preferred to create shiny new bling instead of boring maintenance. That's at the core of this, not the proclaimed, but not existing, differences between those pages. And the phab is just a strawman as well, if you mange to get templates programmed somehow, the indentation problem should be non-existing. Unles you deliberately choose not to do something about it, to keep this strawman alive.

MZMcBride (talkcontribs)

Hmmm. Does "support VisualEditor on talk pages" have an associated Phabricator Maniphest task?

I tend to agree with Sänger, though I'd perhaps phrase it this way: VisualEditor should work with all regular (non-Special) wiki pages. This includes user pages, talk pages, portal pages, pages in the MediaWiki namespace, etc. It's an extensible editor that we've already installed and committed to supporting. We've seen time and again that the arbitrary distinction put up between VisualEditor support by namespace is confusing and annoying to users.

I think there are talks about unifying the wikitext and VisualEditor editors. Eliminating or masking the difference between the two or more editors that we have may somewhat neatly resolve this issue.

Whatamidoing (WMF) (talkcontribs)

To see the result of these "talks", go to Special:Preferences#mw-prefsection-betafeatures and enable the "new wikitext mode" beta feature.

NB that it's not really about "unifying the [old] wikitext and VisualEditor editors". This will not merge the code for EditPage.php or Extension:WikiEditor with Extension:VisualEditor. The only thing that's being unified is the user experience, i.e., the user gets VisualEditor's black-and-white toolbar and VisualEditor's built-in tools (such as pasting a URL to a Wikipedia page and getting an internal wikilink instead of an external link) everywhere. There will still not be any visual mode on the talk pages.

Sänger (talkcontribs)

And there is still no believable reason given, why a wikipage is not a wikipage. It's just futile justification lyricism for not wanting to do anything against Flow.

This post was hidden by (history)
Reply to "Why isn't the VE running on talk pages anywhere?"