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?
About this board
|This is not the place for bug reports about VisualEditor - those should go on the feedback page.|
Previous discussion was archived aton 2015-09-01.
Can you remove tools/gadgets from the toolbar?
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.).
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)
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.
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
I wonder whether VisualEditor/Gadgets would be useful to you.
Parsoid/RESTbase working for Main Page but 404ing for sub-pages
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
Insert Media (and other) doesn't work
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?
I'm sorry, but I don't know how to install this. However, most people seem to ask about installation problems at Project:Support desk or on Extension talk:VisualEditor, so perhaps it would be worth looking at those pages.
Thank you. I try it there.
Force Line Breaks in VE
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.
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.
VisualEditor Error: Could not connect to the server
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.
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).
Media settings search is incomplete
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
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?
If you are not using CirrusSearch or another fulltext search engine, you have to use search parameter like
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
Try to use wildcards like
M*. That may helps.
Unable to stop the editor from loading while offline
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.
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?
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,
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.
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?
There won't be any real answer at any time.
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?
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).
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.
Why was this definitely not solved question closed? Your answer was just a straw man, not a real one. It's everything but closed.
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.
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.
VE is a text editor,
As I explained, this is not true.
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?
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.
...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?
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., https://www.wikidata.org/wiki/Wikidata:Project_chat ), 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.
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.
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.
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.
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.
Error saving data to server: Empty server response
Error saving data to server: Empty server response
Please help! we have installed new visual editor and parsoid on our wiki, and all user have the problem with articel edititing. when articel have a external link, he cant be saved by users, but not by admins.
How we can enable editing with external links for all default users?
# The following permissions were set based on your choice in the installer $wgGroupPermissions['*']['createaccount'] = false; // Registrierung verbieten $wgGroupPermissions['*']['edit'] = false; // Bearbeitung verbieten $wgGroupPermissions['*']['read'] = false; // Lesezugriff verbieten $wgGroupPermissions['*']['createpage'] = false; // Schreibzugriff verbieten $wgGroupPermissions['*']['upload'] = false; // Dateien hochladen verbieten $wgGroupPermissions['*']['reupload-shared'] = false; // Ersetzen von bestehenden Dateien verbieten $wgGroupPermissions['*']['upload_by_url'] =false; // Hochladen durch eingeben einer neuen URL verbieten $wgGroupPermissions['*']['autocreateaccount'] = true; $wgVirtualRestConfig['modules']['parsoid'] = array( // URL to the Parsoid instance // Use port 8142 if you use the Debian package 'url' => 'http://wiki-aws.cib.de:8142', // Parsoid "domain", see below (optional) 'domain' => 'wiki-aws.cib.de', // Parsoid "prefix", see below (optional) // 'prefix' => 'localhost' ); require_once "$IP/extensions/VisualEditor/VisualEditor.php"; $wgDefaultUserOptions['visualeditor-enable'] = 1; $wgHiddenPrefs = 'visualeditor-enable'; $wgDefaultUserOptions['visualeditor-enable-experimental'] = 1; $wgDefaultUserOptions['visualeditor-editor'] = "visualeditor"; $wgSessionsInObjectCache = true; $wgVirtualRestConfig['modules']['parsoid']['forwardCookies'] = true;
Best regards, Vadim
I'm sorry, I can't really help you. But I saw that error message the other day, when my internet connection dropped for a few minutes.
Can your regular editors save a page (with a URL) when they use other editing tools?
Hi! Yes, standard mediawiki editor can save a page with a URL
following settings in Localsettings.php have fixed the problem:
$wgGroupPermissions['emailconfirmed']['skipcaptcha'] = true;
$ceAllowConfirmedEmail = true;
hopefully, it will not bring any new problems now
Thanks for posting the solution! I hope that it helps someone else.